Licensing of specs and artifacts
hi > we should certainly examine the discussions you have had in FHIR-land. The discussions were all private threads, but I can give you a summary run down. We start with our plain english license: * FHIR is ? and ? HL7. The right to maintain FHIR remains vested in HL7 * You can redistribute FHIR * You can create derivative specifications or implementation-related products and services * Derivative Specifications cannot redefine what conformance to FHIR means * You can't claim that HL7 or any of its members endorses your derived [thing] because it uses content from this specification * Neither HL7 nor any of the contributors to this specification accept any liability for your use of FHIR Our intent here is a license for a standard: lots of commercial companies are going to be forced to use it (eventually), and lots of open source applications too. What can we do to make that easy? Well, we let anyone do anything, as long as they can't grab control of the actual spec. For FHIR, at least, that's vested in HL7, so when we think about grabbing control, we think in terms of "from HL7". There's another set of considerations there too: with a lot of existing specifications, implementation guides - which are very derivative works - are in a grey zone. In fact, my opinion is the bulk of Australian HL7 derived standards are not ok against the HL7 license (and lots of other IGs too...), but HL7 affiliates don't push the issue because we want adoption. Well, they don't usually push the issue - and if they do, it's extremely self-destructive. But we wanted to be explicit and clear: whatever you need to do in an implementation guide, go do it with no worry about 'surprises' later (they tend to be expensive). The outcome is what matters: you use our common standard, and it's good for you, us, the providers and the consumers. Oh, and, btw we also need to assure implementers that HL7 will not be a capricious or undeserving steward of the work, so we don't try and come up with some exclusivity with the license, whereby some derivatives are ok, and some aren't. Whatever people want, that's fine. We'll just be the best steward we can be. So we started with that notional agreement. Which, I must say, seems to me to apply to openEHR. I know that there's some in the community who think that there should be some limits to commercial use for one reason or another, or that if companies 'benefit' from the community, they should be obliged to put back in (a Stallman kind of thing, but I think that's self-limiting. we all have to earn a buck). It seems to me that this kind of thinking doesn't apply to openEHR - the goals are to help exchange health data, and unless there's some collective fantasy that people are going to start providing healthcare for free, it's always going to have a commercial element. So we knew what we wanted. Initially, we considered the available CC licenses, and others, and rejected them because they didn't have anything in them about redefining conformance to the publication. As a work around we adapted a license from the OMG, but that's not really open, and it was generating problems for us because - the fine print didn't quite say what we said in plain English - because it wasn't a standard license, people needed to review it / pay for lawyers to review it - using a non-standard license meant that some purists claimed we weren't really open I wanted to fix that, but the process of getting lawyer time and dealing with the organizational approval process just seemed like too big a mountain to climb So Paul Biondich from OpenMRS got in contact with me, and offered to pay for lawyer time to resolve this (I really appreciated that). His lawyer (Larry Rosen) and I went back and forth on the plain english license making sure that he understood exactly what we wanted. For instance, our conformance thing wasn't a play for total control of the eco-system (unlike some other companies), just a play to retain control over the specification. Once he was clear what we wanted, he pointed us at CC-0 - it does what we want (btw, Larry would like us to do more about patents - as would I - but that really is a mountain too big to climb). When I raised the issue of conformance not being covered by the license, he pointed out that this is a not a *copy*ing issue, but a *control of meaning*, e.g. trademark issue. So we agreed that we would (a) adopt CC-0 and (b) beef up the trademark protection. HL7's own lawyer wasn't really comfortable with allowing derivative works, but that was actually an issue with our intent. We need to allow derivative works because there's too many things that should be allowed that a reasonably described as derivative works. So I proposed this to HL7, and Chuck Jaffe (HL7 CEO) took on the herculean task of steering that change through the organization (it should have been straight forward because we weren't changing the intent, but these things never are straight forward). We beefed up the
Licensing of specs and artifacts
This is why we choose CC-0 for FHIR. End of story, there are no debates. Sure, people can go and try and make money off FHIR. All power to them. But times have changed - if they're intending to compete, they won't stay ahead of the community nowadays. So anyone worth working with will share the common stuff, and focus on making money using and leveraging our IP. Which is what we want to happen. Other people have raised the concern that people will be able predate the work and take it away from us. Not so. They have confused trademark, patents, and copyright. We yielded copyright. Trademark we explicitly did not, and patents that's a complicated story of it's own. But public prior art is the best defense against patents, and FHIR is busy creating public prior art. Of course, openEHR has been doing so for a lot longer Grahame On Thu, Oct 2, 2014 at 6:03 PM, Thomas Beale wrote: > > At the end of the day, I don't really care what licence is used for these > things in openEHR - maybe the community should just vote. The long debates > from the past are summarised here and here. This page contains one attempt I > made to state the requirements for each kind of openEHR IP. > > Nevertheless, here are some new thoughts, based on a review of CC-BY-SA > 4.0 > > I think the key things to remember in resolving this are how the various > artefacts get used, which helps figure where 'adaptation' actually exists. I > can think of the following: > > archetype => template => software application > > the simplest standard practice > this is USE not ADAPTATION > > archetype => specialise => template => software application > > the next simplest standard practice > this is USE not ADAPTATION > > archetype => software application > > not a great idea in general - it means that the 'archetypes' are not really > maximal re-usable data sets, but something like predefined templates. > However, someone is bound to do this, and produce a good product from it. > this is USE not ADAPTATION > > archetype => forking => modification => templating => software application > > Result: probably non-interoperable data; but may occur for pragmatic > reasons, e.g. openEHR is too slow to make fixes to the archetype. > this is ADAPTATION > > According to the CC-BY-SA 4.0 licence text only the last of these paths > means that the final software or other result is an 'adaptation' of the > original archetype, which means that the CC-BY-SA license applies, IF YOU > PUBLICLY SHARE THE ARTEFACT. > > Here is relevant licence text from the CC site (my bolding): > > Adapted Material means material subject to Copyright and Similar Rights that > is derived from or based upon the Licensed Material and in which the > Licensed Material is translated, altered, arranged, transformed, or > otherwise modified in a manner requiring permission under the Copyright and > Similar Rights held by the Licensor. For purposes of this Public License, > where the Licensed Material is a musical work, performance, or sound > recording, Adapted Material is always produced where the Licensed Material > is synched in timed relation with a moving image. > Share means to provide material to the public by any means or process that > requires permission under the Licensed Rights, such as reproduction, public > display, public performance, distribution, dissemination, communication, or > importation, and to make material available to the public including in ways > that members of the public may access the material from a place and at a > time individually chosen by them. > > > 3b ShareAlike. > > In addition to the conditions in Section 3(a), if You Share Adapted Material > You produce, the following conditions also apply. > > The Adapter?s License You apply must be a Creative Commons license with the > same License Elements, this version or later, or a BY-SA Compatible License. > You must include the text of, or the URI or hyperlink to, the Adapter's > License You apply. You may satisfy this condition in any reasonable manner > based on the medium, means, and context in which You Share Adapted Material. > You may not offer or impose any additional or different terms or conditions > on, or apply any Effective Technological Measures to, Adapted Material that > restrict exercise of the rights granted under the Adapter's License You > apply. > > > In contrast to what David says, I don't believe a technical transformation > of an archetype, say into some kind of XML or JSON would be a modification > of the original artefact, it's just a downstream conversion, like rendering > an original document written in MarkDown or Wikimedia-markup into HTML. > That's what Wikipedia and Github and hundreds of other sites already do, and > that rendering is not regarded as an 'adaptation' to my knowledge. > > So I think the real legal question is about the last path above - forking > archetypes, modifying the (copy of the) original and then doing something > with that, followed by public sha
Licensing of specs and artifacts
about openEHR. The fact that W3C licensing disallows forks does not dictate that openEHR needs to go the same direction. Using only CC-BY or CC-0 on the specs might be a good FUD-killer, nobody then needs to trust that openEHR governance will stay fit in the future. If the openEHR organization gets overtaken or deadlocked, then forking can occur and progressive people/companies that want to develop new improved versions can do that (if they call the new thing something else than openEHR). Whether such possibilities put bad or healthy pressures on an organization is of course open to debate. W3C seems to see forking as a risk or consider themselves big/trusted enough to not get deadlocked/overtaken. Many open source projects on the other hand see forking-possibilities as a healthy emergency safeguard against potentially poor future governance/leadership. I agree with Bert in the Linkedin-discussion, that it will most likely be possible to continue creating openEHR-compatible software from currently published CC-BY-ND licensed specifications, even if there is a ?hostile takeover? or deadlock of the organization. Especially if all computable specification items (class definitions etc.) are released under Apache 2 license (I believe that is the current intention). What is published is already out there and free to use, it can never be taken back. The ND-clause mainly causes problems for those that in a deadlock/takeover situation want to fork the project and keep working on _new_ future/updated versions of the specification. What the ND actually in practice would protect openEHR against is less obvious to me though. Thus the ND only adds to the confusion/FUD without bringing any obvious big benefit. (W3C gets away with it though.) Compatibility issues are better managed through testing and certification than licensing. Licenses won?t stop errors, or non-conformance. Phew? amazing if you had the energy to read all the way down to here. Tom, regarding what it means to sell Share-Alike (SA) artifacts, I think you can compare that to http://www.gnu.org/philosophy/selling.html Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Li?: erik.sundvall at lio.se http://www.lio.se/itc/ & http://www.lio.se/testbadd LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ On Thu, Oct 2, 2014 at 4:14 PM, Grahame Grieve < grahame at healthintersections.com.au> wrote: > > >> Controlling Conformance: CC-0 just means 'public domain', no copyright. How do you exert any kind of control (which you mention) over the conformance not being messed with? > > > The point of a trademark is that you can control what the name means. We say that we define what conformance to "FHIR" means. We expect that conformance will be messed with - that's just how it works. But no one else is allowed to say what it means to be "conformant to FHIR" because hl7 owns that trademark > > Also, we don't assert any rights around copying, but that doesn't mean that hl7 isn't the recognised author. > >> Copyright: I don't see any harm in having a copyright notice if the original author(ity) demands it, e.g. Nehta is like this. Copyright is kind of useless in the land of software and formal models anyway, it's the licence that counts. > > > Well, the way I understand it, with FHIR now, someone can asset a copyright on a derived work, but they could not effectively enforce copyright provisions on the content they include from the FHIR spec. There might not be much left... >> >> >> Attribution: Current thinking has been that if archetypes are copyrighted to whomever, the licence-to-use would require attribution, which just means listing authors. I think the value here is that artefact users know that wide consultation and expertise went into the artefact. > > > I don't think there's any relationship between attribution and copyright. We could choose to attribute if we wanted to. Actually, we do it at the spec level: http://hl7.org/implement/standards/fhir/credits.html#credits >> >> >> Would't that 'contributors' list disappear under the new FHIR approach? > > > No, they're still the contributors. > >> Grahame > > - > http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/af556f4a/attachment-0001.html>
Licensing of specs and artifacts
But some 'derived' artifacts should also list the original contributors as authors? Doesn't make much sense to me. 2014-10-02 15:53 GMT+02:00 Thomas Beale : > > Grahame, > > thanks for this, it's very useful. Some questions... > > *Controlling Conformance*: CC-0 just means 'public domain', no copyright. > How do you exert any kind of control (which you mention) over the > conformance not being messed with? Is it just that 'FHIR' is stamped on > everything, and trademark protection actually defines the rights of use? In > which case, aren't we talking about some other piece of legalese to do with > the trademark, that defines when something could have a 'FHIR' trademark on > it? > > *Copyright*: I don't see any harm in having a copyright notice if the > original author(ity) demands it, e.g. Nehta is like this. Copyright is kind > of useless in the land of software and formal models anyway, it's the > licence that counts. > > *Attribution*: Current thinking has been that if archetypes are > copyrighted to whomever, the licence-to-use would require attribution, > which just means listing authors. I think the value here is that artefact > users know that wide consultation and expertise went into the artefact. > Consider for example the BP archetype in CKM: > > > > Would't that 'contributors' list disappear under the new FHIR approach? I > think that would be a problem for openEHR - the contributors list is the > main way that users can get some idea of the quality of the thing. > > > - thomas > > On 02/10/2014 14:05, Grahame Grieve wrote: > > hi > > > we should certainly examine the discussions you have had in FHIR-land. > > The discussions were all private threads, but I can give you a summary > run down. We start with our plain english license: > > * FHIR is ? and ? HL7. The right to maintain FHIR remains vested in HL7 > * You can redistribute FHIR > * You can create derivative specifications or implementation-related > products and services > * Derivative Specifications cannot redefine what conformance to FHIR means > * You can't claim that HL7 or any of its members endorses your derived > [thing] because it uses content from this specification > * Neither HL7 nor any of the contributors to this specification accept > any liability for your use of FHIR > > > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/c4233cf0/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: bejcgidi.png Type: image/png Size: 44922 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/c4233cf0/attachment-0001.png>
Licensing of specs and artifacts
Grahame, thanks for this, it's very useful. Some questions... *Controlling Conformance*: CC-0 just means 'public domain', no copyright. How do you exert any kind of control (which you mention) over the conformance not being messed with? Is it just that 'FHIR' is stamped on everything, and trademark protection actually defines the rights of use? In which case, aren't we talking about some other piece of legalese to do with the trademark, that defines when something could have a 'FHIR' trademark on it? *Copyright*: I don't see any harm in having a copyright notice if the original author(ity) demands it, e.g. Nehta is like this. Copyright is kind of useless in the land of software and formal models anyway, it's the licence that counts. *Attribution*: Current thinking has been that if archetypes are copyrighted to whomever, the licence-to-use would require attribution, which just means listing authors. I think the value here is that artefact users know that wide consultation and expertise went into the artefact. Consider for example the BP archetype in CKM: Would't that 'contributors' list disappear under the new FHIR approach? I think that would be a problem for openEHR - the contributors list is the main way that users can get some idea of the quality of the thing. - thomas On 02/10/2014 14:05, Grahame Grieve wrote: > hi > >> we should certainly examine the discussions you have had in FHIR-land. > The discussions were all private threads, but I can give you a summary > run down. We start with our plain english license: > > * FHIR is ? and ? HL7. The right to maintain FHIR remains vested in HL7 > * You can redistribute FHIR > * You can create derivative specifications or implementation-related > products and services > * Derivative Specifications cannot redefine what conformance to FHIR means > * You can't claim that HL7 or any of its members endorses your derived > [thing] because it uses content from this specification > * Neither HL7 nor any of the contributors to this specification accept > any liability for your use of FHIR > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/a98aaddf/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: bejcgidi.png Type: image/png Size: 44922 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/a98aaddf/attachment-0001.png>
Licensing of specs and artifacts
On 02/10/2014 09:25, David Moner wrote: > > > > And it is also important to note that if you sell a software you are > also publicly sharing it. Publicly share does not imply for free, but > outside of a personal use. this actually seems to be the most important point. The following definition, (especially the last bit) of 'share' doesn't mention commercial sale, and to me it doesn't read as if selling could be included: *Share*means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the *public may access the material from a place and at a time individually chosen by them*. Does anyone know definitively if this commercial sale is meant to be included here? > > I fully support the comments of Grahame. Probably the solution is to > go just for the simpler option and don't worry about what others do > with their own business. I also incline to the same opinion... - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/c8195c50/attachment.html>
Licensing of specs and artifacts
Grahame, we should certainly examine the discussions you have had in FHIR-land. Is there a link to any discussion, debate on this (i.e. we know what the result it, but what was the thinking along the way?) - thomas On 02/10/2014 09:11, Grahame Grieve wrote: > This is why we choose CC-0 for FHIR. End of story, there are no debates. > > Sure, people can go and try and make money off FHIR. All power to > them. But times have changed - if they're intending to compete, they > won't stay ahead of the community nowadays. So anyone worth working > with will share the common stuff, and focus on making money using and > leveraging our IP. Which is what we want to happen. > > Other people have raised the concern that people will be able predate > the work and take it away from us. Not so. They have confused > trademark, patents, and copyright. We yielded copyright. Trademark we > explicitly did not, and patents that's a complicated story of it's > own. But public prior art is the best defense against patents, and > FHIR is busy creating public prior art. Of course, openEHR has been > doing so for a lot longer > > Grahame >
Archetype Naming proposals - do we need V0?
Hi Diego, There will be a v2 very soon. It will be the first of the small number of published archetypes that has had backwardly incompatible changes required. It is Indirect Oximetry which will go out for further review next week, but we already have had a breaking error identified. Regards Heather -Original Message- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Diego Bosc? Sent: Thursday, 2 October 2014 5:48 PM To: For openEHR technical discussions Cc: For openEHR clinical discussions Subject: Re: Archetype Naming proposals - do we need V0? I agree with your points. I would say that some of your points are the reasons people is reluctant in adopting openEHR more. It's not all about licenses. It has always puzzled me why there is not a single v2 archetype in CKM after 7 years. 2014-10-02 9:17 GMT+02:00 Sebastian Iancu : > Hi Sebastian G, David M, > > > Thank you for your elaborate answers. > > I can proudly say, years ago, we were one of the early adopters of openEHR. > We've been there (in fact actively participating) when the CAM-hash > was introduced, or when .v1draft was replaced with .v1, or when the > archetype_id versioning policy was polished, or when Thomas started to > work on distributed knowledge management and artefact identification. > I'm not a stranger to the fact that CKM archetypes are changing > without having their version updated, sometimes breaking existing > specifications. I also acknowledge the benefits of the > industry-sprint, and that we need clearing things out in CKM content > for that. Finally, as technician, I'm aware of the impact of using > 'draft'-like artefacts in own software. > > But, I cannot agree with a mass regression to v0: > > What's the point of having this boolean logic where draft=0, stable=1? > Are we never going to have v2? And if yes, would that mean something > (published-on-Mars-aswell, or sprint-2)? The version itself should not > be important (we can have v1 or v87), it matters only in relation with > other versions and a timeline. > There are already released specification about versioning, so why > violate them doing odd regression? > There is no guaranty that all current drafts will be published some > day - in which case we might be stuck with v0, while v1 was already > available up to 2014. Why should we destroy something that already exists and > it works? > We know CKM content is not perfect, archetype changes are not fully > considered in their version - why should we create even more mess? > > Furthermore, for my point of view: > > you hardly get early adopters if you discourage them to use 'draft' > archetypes > an archetype uploaded on CKM is in fact sort-of technically published, > although not domain-published. Breaking it constantly makes it > unusable and lowers the adoption or real-life testing chances. > encouraging vendors or consumers to use their own archetype > repositories (own namespaces) as opposed to a global own (CKM) is a > threat to interoperability, and defies some of the openEHR principles. > > > In conclusion, > I'm not at all against the new versioning identification, discussed > these days (i.e v1.2.3, etc), as long as it is introduced only in/for > upcoming specifications (ADL 1.5, 2.0 whatever) and it is not breaking > existing systems based on RM 1.0.2 and ADL 1.4 archetypes. Keep things > simpler and don't focus too much on only syncing with semver, while > you forget the big picture where these archetypes are actually used > for (namely to describe data). > > Sebastian > Code24 > > > > On 10/1/2014 5:44 PM, Sebastian Garde wrote: > > Hi Sebastian, > > I realise you are physically not too far away from me in Germany and > we even share the same name, so I hope you won't shoot the messenger > here, but I have to say the following... > > The consequence of what you are saying would be that we cannot publish > any > v1 archetype if it is already on CKM without an analysis if there have > been any breaking changes anywhere during the development and review > process (which would be the case in most cases I suspect). > > However, this is the case with or without any of the changes being > discussed > here: It doesn't matter if draft archetypes become v0 for a while: > once they are published they'd be v1 again anyway - and likely > incompatible with the previous v1. > If on the other hand, you leave the CKM draft archetypes as v1 and > they are published subsequently, there is also no guarantee whatsoever > that the published version is compatible with any draft revision (or > any of the draft revisions with each other). > Either way, if you use them now, no, you cannot just replace a draft > archetype with the next revision of the draft archetype or its > subsequently published revision. You cannot do it now, because there > is no guarantee that they'd be compatible and you cannot do it with or > without v0. > > So
Archetype Naming proposals - do we need V0?
ble change to an archetype >> that would cause a replacement of the archetype - the only difference >> being that the namespace is changed, not the version number in this case. >> >> As I said I believe that this is a problem regardless of v0 or not >> and that it certainly is a problem of some sort for about every vendor. >> Therefore, I think it deserves a thorough discussion in a separate >> thread. >> Could you start this thread if you agree with me that this is a >> general problem rather than a v0 or v1 problem? >> >> Cheers >> Sebastian >> >> On 01.10.2014 15:35, Sebastian Iancu wrote: >>> Dear all, >>> >>> I'm surprise to see such a low analysis of the impact of changing v1 >>> to v0 of the existing CKM archetypes. >>> Even though they are not 'published', or are in logical 'draft' >>> mode, they were conformant to openEHR standards for at least past 5 >>> years or so. Some of them are used already in production >>> environments for more than 2-3 years (at least in our case). >>> Changing them now on CKM will break logical binding with already >>> existing production data. This cost has to be eventually supported >>> by industry implementers, and I can assure you this is not trivial, >>> and it is giving the impression that openEHR standard is not >>> reliable/stable enough. >>> >>> Basically the proposal is to rename existing CKM archetypes >>> (published or not) in contradiction with what the current openEHR >>> specifications is stating right now, which is not right. >>> >>> Other than this, I personally think that is nice to have v0 for >>> 'drafts', and v1 for stable-published; it might be a better >>> indication about a state of an archetype. >>> So my suggestion is to keep existing CKM archetypes the way they are >>> and only apply the new 'rule' for archetypes created from now one. >>> Published archetypes from the sprint can become v2 (or 3, 4 etc) >>> depends on the need (see specifications). >>> >>> Sebastian >>> Code24 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/ebbd8c98/attachment-0001.html>
Licensing of specs and artifacts
2014-10-02 10:03 GMT+02:00 Thomas Beale : > > > I think the key things to remember in resolving this are how the various > artefacts get used, which helps figure where 'adaptation' actually exists. > I can think of the following: > >- archetype => template => software application > - the simplest standard practice > - this is USE not ADAPTATION >- archetype => specialise => template => software application > - the next simplest standard practice > - this is USE not ADAPTATION >- archetype => software application > - not a great idea in general - it means that the 'archetypes' are > not really maximal re-usable data sets, but something like predefined > templates. However, someone is bound to do this, and produce a good > product > from it. > - this is USE not ADAPTATION >- archetype => forking => modification => templating => software >application > - Result: probably non-interoperable data; but may occur for > pragmatic reasons, e.g. openEHR is too slow to make fixes to the > archetype. > - this is ADAPTATION > > According to the CC-BY-SA 4.0 licence text only the last of these paths > means that the final software or other result is an 'adaptation' of the > original archetype, which means that the CC-BY-SA license applies, IF YOU > PUBLICLY SHARE THE ARTEFACT. > > Just to be clear, I repeat that that is exactly what I would like to interpret. But if I read the legal texts trying to be objective (and again, not being a lawyer!) it is normal that doubts arise. If I generate a validation software that includes validation rules from the archetype constraints, that is arguably an adaptation, not just a use. And it is also important to note that if you sell a software you are also publicly sharing it. Publicly share does not imply for free, but outside of a personal use. I fully support the comments of Grahame. Probably the solution is to go just for the simpler option and don't worry about what others do with their own business. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/b357fa49/attachment.html>
Archetype Naming proposals - do we need V0?
I agree with your points. I would say that some of your points are the reasons people is reluctant in adopting openEHR more. It's not all about licenses. It has always puzzled me why there is not a single v2 archetype in CKM after 7 years. 2014-10-02 9:17 GMT+02:00 Sebastian Iancu : > Hi Sebastian G, David M, > > > Thank you for your elaborate answers. > > I can proudly say, years ago, we were one of the early adopters of openEHR. > We've been there (in fact actively participating) when the CAM-hash was > introduced, or when .v1draft was replaced with .v1, or when the archetype_id > versioning policy was polished, or when Thomas started to work on > distributed knowledge management and artefact identification. I'm not a > stranger to the fact that CKM archetypes are changing without having their > version updated, sometimes breaking existing specifications. I also > acknowledge the benefits of the industry-sprint, and that we need clearing > things out in CKM content for that. Finally, as technician, I'm aware of the > impact of using 'draft'-like artefacts in own software. > > But, I cannot agree with a mass regression to v0: > > What's the point of having this boolean logic where draft=0, stable=1? Are > we never going to have v2? And if yes, would that mean something > (published-on-Mars-aswell, or sprint-2)? The version itself should not be > important (we can have v1 or v87), it matters only in relation with other > versions and a timeline. > There are already released specification about versioning, so why violate > them doing odd regression? > There is no guaranty that all current drafts will be published some day - in > which case we might be stuck with v0, while v1 was already available up to > 2014. Why should we destroy something that already exists and it works? > We know CKM content is not perfect, archetype changes are not fully > considered in their version - why should we create even more mess? > > Furthermore, for my point of view: > > you hardly get early adopters if you discourage them to use 'draft' > archetypes > an archetype uploaded on CKM is in fact sort-of technically published, > although not domain-published. Breaking it constantly makes it unusable and > lowers the adoption or real-life testing chances. > encouraging vendors or consumers to use their own archetype repositories > (own namespaces) as opposed to a global own (CKM) is a threat to > interoperability, and defies some of the openEHR principles. > > > In conclusion, > I'm not at all against the new versioning identification, discussed these > days (i.e v1.2.3, etc), as long as it is introduced only in/for upcoming > specifications (ADL 1.5, 2.0 whatever) and it is not breaking existing > systems based on RM 1.0.2 and ADL 1.4 archetypes. Keep things simpler and > don't focus too much on only syncing with semver, while you forget the big > picture where these archetypes are actually used for (namely to describe > data). > > Sebastian > Code24 > > > > On 10/1/2014 5:44 PM, Sebastian Garde wrote: > > Hi Sebastian, > > I realise you are physically not too far away from me in Germany and we even > share the same name, so I hope you won't shoot the messenger here, but I > have to say the following... > > The consequence of what you are saying would be that we cannot publish any > v1 archetype if it is already on CKM without an analysis if there have been > any breaking changes anywhere during the development and review process > (which would be the case in most cases I suspect). > > However, this is the case with or without any of the changes being discussed > here: It doesn't matter if draft archetypes become v0 for a while: once they > are published they'd be v1 again anyway - and likely incompatible with the > previous v1. > If on the other hand, you leave the CKM draft archetypes as v1 and they are > published subsequently, there is also no guarantee whatsoever that the > published version is compatible with any draft revision (or any of the draft > revisions with each other). > Either way, if you use them now, no, you cannot just replace a draft > archetype with the next revision of the draft archetype or its subsequently > published revision. You cannot do it now, because there is no guarantee that > they'd be compatible and you cannot do it with or without v0. > > So, while I certainly acknowledge the problem (more below), it is not a > problem that is caused or increased by migrating draft archetypes to v0. > > And in fact solving this problem is one of the core reasons for the proposed > revisioning rules. > You will know exactly where you are at and how compatible two archetypes > are. > > So, if you as a company use draft archetypes, this is the risk you have > taken - draft archetypes just cannot be assumed stable or backwardly > compatible just because they happen to be expressed in (more or less) > correct ADL. > The impression that draft archetypes are stable has of course been given by > the lack of activity i
Archetype Naming proposals - do we need V0?
1.x, and others that are of >>>>> unknown quality should go to v0, which finally establishes >>>>> what is clinically trustworthy and what is not. >>>>> >>>> That's not really an option unless you want to make this migration >>>> even more difficult. >>>> What you are suggesting requires two different sets of rules and >>>> someone needing to deciding which stays at v1 and which is >>>> converted to v0. >>>> I don't think it makes sense - either we use v0 to indicate >>>> pre-publication archetypes or we don't. >>> >>> I would have thought that individual archetypes can have their >>> version modified? I don't think the world minds if there is a period >>> of a few months during the industry sprint when the rules are >>> technical being broken. Once it's done, there will be 70+ archetypes >>> with v1.x, and the rest with v0.x, and that will correctly represent >>> the situation of the archetypes in CKM. >>> >>> Then for every mirroring, copy, and reuse of what's in openEHR.org >>> CKM, there is no need to educate anyone on anything - it's obvious >>> what the situation is. So we are only talking about a limited period >>> of time where the rules are being broken (as they are right now in >>> fact ;-) >>> >>>>> >>>>> * I don't see the problem with v0 references in templates, since >>>>> it's the same problem between any major version. An archetype >>>>> .v0.x can't be assumed to be compatible with .v1.y - >>>>> as for other major versions, we treat them technically as >>>>> different archetypes. So either the template reference is v* >>>>> (any major version you like) or it isn't, in which case it >>>>> points to a known major version - v0, v1, v2 or other. >>>>> o we should assume that future tools will make it easy to >>>>> change these template references - it won't be difficult >>>>> to do. >>>>> >>>> Sure, looking forward to tooling support on it, but realistically >>>> at the moment it is a pain that is not needed for the first >>>> publication if you go with v1 as a the initial major version. >>> >>> well I think its a bigger danger, given the level of reuse of CKM >>> archetypes, that the version ids wouldn't correct reflect the state >>> of the archetypes. We could in theory revert everything that is not >>> published to v0 right now, and i guess that is breaking the rules >>> for less time. But there are still some dozens of fully reviewed and >>> published archetypes that have to retain their v1.x version anyway. >>> So I think the only question is to do with the industry sprint >>> archetypes. How about doing this: >>> >>> * mark archetypes that have never been 'published' and are not in >>> the industry sprint as v0.5.0 >>> * mark the industry sprint archetypes as v1.0.0-unstable >>> * leave currently published archetypes on v1.x, i.e. where they >>> are today. >>> >>> If I receive a copy of archetypes marked like that in say the GitHub >>> mirror, or through a different CKM, I don't need any further >>> education, it's obvious what's going on. >>> >>> - thomas >>> >>> >>> >>> ___ >>> openEHR-clinical mailing list >>> openEHR-clinical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > -- > *Dr. Sebastian Garde* > /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ > Ocean Informatics > > Skype: gardeseb > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/133763c7/attachment-0001.html>
Licensing of specs and artifacts
s out that either technical transformation, including technical use via compilation into software, constitutes 'adaptation'. HOWEVER... on reading the non-legal text of CC-BY-SA 4.0 <http://creativecommons.org/licenses/by-sa/4.0/>, the impression it gives is quite different from (my reading of) the legal code! It says: * *ShareAlike*--- If you remix, transform, or build upon the material, you must distribute your contributions under thesame license <http://creativecommons.org/licenses/by-sa/4.0/#>as the original. That gives the impression that if you make a changed version of a source work, you have to share your result. But in fact it is trying to say that IF you openly share the modified source work (not the final result), you must share with the same license as the source work itself. I think the short form of this licence is one of the problems here - it makes it look like you have to share derivative material, but that's not the case. The licence in fact just prevents you from sharing derivative material under a different licence, and without proper attribution. - thomas On 02/10/2014 08:00, David Moner wrote: > Hahaha, it's good you always have LinkEHR in mind ;-) > > By the way, this is certainly an old and recurring topic. I have > checked that there were already discussions back in 2009, so probably > we are going to repeat things already commented. > > I will talk about artefacts (archetypes). The first thing to solve in > my opinion is to agree on what does "derivative work" mean for an > archetype. Is just modified archetypes? Auto-generated data base > schemas, validation schematron or other technical artefacts? > Documentation describing the archetype? I would love to say that only > the first case applies, but let's thing in an example. Which is the > license for a movie you make from a CC-BY-SA book? It is for sure a > derivative work, and the Title 17 Section 101 of the Copyright Act of > the United States says it very clear: > > "A derivative work is a work based upon one or more preexisting works, > such as a translation, musical arrangement, dramatization, > fictionalization, motion picture version, sound recording, art > reproduction, abridgment, condensation, or any other form in which a > work may be recast, transformed, or adapted. A work consisting of > editorial revisions, annotations, elaborations, or other modifications > which, as a whole, represent an original work of authorship, is a > derivative work." (http://www.law.cornell.edu/uscode/text/17/101) > > Given that definition I don't think a technical transformation of an > archetype is a different case. So yes, I'm not a lawyer, but I would > say that fears of implementers of commercial products using openEHR > archetypes are reasonable if the the CC-BY-SA license is applied as is. > > David > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/de2da903/attachment-0001.html>
Licensing of specs and artifacts
. > > > > I realise these issues will ultimately be decided by the board of the > openEHR Foundation, but if the community can come to some kind of consensus > on this issue I would hope it'd send them a strong signal. > > Kind regards, > *Silje Ljosland Bakke* > > Coordinator, National Editorial Board for Archetypes, National ICT Norway > Adviser, R&D dept, E-health section, Bergen Hospital Trust > > Tel. +47 40203298 > > > > > ___ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/0b423b40/attachment.html>
Licensing of specs and artifacts
"For information the link to the LinkedEhr discussion, I hope it works" Of course, this should be: LinkedIN ;-) (sorry David) Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: > > Hi everyone, > > In light of the recent re-licensing of FHIR > <http://www.healthintersections.com.au/?p=2248> using the Creative > Commons CC0 Public Domain Dedication as well as the discussion about > licensing at the 2014 openEHR Roadmap Meeting > <http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting> > in Lillestr?m on September 16 and 17, I?d like to restart the > discussion on licensing of openEHR specifications and artefacts > (mainly archetypes, but also potentially templates and terminology sets). > > As of now, the specifications are licensed using the Creative Commons > Attribution No-Derivatives > <http://creativecommons.org/licenses/by-nd/3.0/> (CC-B-ND) license, > while the Creative Commons Attribution Share-Alike > <http://creativecommons.org/licenses/by-sa/3.0/> (CC-BY-SA) is used > for artefacts. Several issues have been raised about this choice of > licences. Feel free to add to this list, I?m bound to have forgot some > issues: > > CC-BY-ND (for specs): > > ?Theoretically, a hostile takeover of the openEHR Foundation might > leave the openEHR specs dead, as with the CC-BY-ND only the copyright > holder (the Foundation) has the rights to modify them. A forkable > license like for instance CC-BY-SA would solve this issue. Global > registering of the openEHR trademark would keep any derivates to be > branded as ?openEHR?. > > CC-BY-SA (for artefacts): > > ?Commercial implementers might avoid using CC-BY-SA artefacts because > the license requires any /published/ modifications of the work to be > licensed using the same license. This might lead implementers to > believe the license would require them to license their entire > software product as CC-BY-SA. There are several examples of CC-BY-SA > works being used in copyrighted works, such as Wikipedia articles > being used in newspapers, but this is probably reliant on a benign > licensor, which any normal commercial company can?t rely 100% on. The > way I see it, this problem could be solved in one of two ways: > > oUse the CC-BY license, which retains the attribution clause, but > doesn?t require any derivative works to use the same license. This has > the disadvantage of enabling proprietary tweaking of archetypes, which > could potentially ruin interoperability. > > oRetain the CC-BY-SA license, but add an explicit clause that allows > all implementers to use artefacts in closed-source, proprietary > products with any license they like. Artefacts published by > themselves, as standalone archetypes, templates or terminology sets > would still be bound by the ShareAlike clause. This is supported by > Creative Commons via the CC+ <https://wiki.creativecommons.org/CCPlus> > protocol. > > I realise these issues will ultimately be decided by the board of the > openEHR Foundation, but if the community can come to some kind of > consensus on this issue I would hope it?d send them a strong signal. > > Kind regards, > *Silje Ljosland Bakke* > > Coordinator, National Editorial Board for Archetypes, National ICT Norway > Adviser, R&D dept, E-health section, Bergen Hospital Trust > > Tel. +47 40203298 > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/26c7bb0b/attachment-0001.html>
Licensing of specs and artifacts
Thanks Silje, that you bring this very important subject under attention. It was already under attention recently on a LinkedIn discussion, but I am afraid it did not reach the right people. I do agree with your point of view, so there is not much discussion, there is only one small remark. I don't see any point in retaining the CC-BY-SA license, with extra clause. First, CC-BY-SA prevents the secret proprietary use of OpenEHR-archetypes, in industry this can be a reason not to use OpenEHR. Except from that, CC-BY-SA is not by everyone understood and is a source of FUD (Fear, Uncertainty, Doubt), even with extra clause, it will remain a source of FUD. For information the link to the LinkedEhr discussion, I hope it works https://www.linkedin.com/groups/Membership-144276%2ES%2E5909661200660054019?trk=groups_most_popular-0-b-ttl&goback=%2Egde_144276_member_5909661200660054019%2Egmp_144276 Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: > > Hi everyone, > > In light of the recent re-licensing of FHIR > <http://www.healthintersections.com.au/?p=2248> using the Creative > Commons CC0 Public Domain Dedication as well as the discussion about > licensing at the 2014 openEHR Roadmap Meeting > <http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting> > in Lillestr?m on September 16 and 17, I?d like to restart the > discussion on licensing of openEHR specifications and artefacts > (mainly archetypes, but also potentially templates and terminology sets). > > As of now, the specifications are licensed using the Creative Commons > Attribution No-Derivatives > <http://creativecommons.org/licenses/by-nd/3.0/> (CC-B-ND) license, > while the Creative Commons Attribution Share-Alike > <http://creativecommons.org/licenses/by-sa/3.0/> (CC-BY-SA) is used > for artefacts. Several issues have been raised about this choice of > licences. Feel free to add to this list, I?m bound to have forgot some > issues: > > CC-BY-ND (for specs): > > ?Theoretically, a hostile takeover of the openEHR Foundation might > leave the openEHR specs dead, as with the CC-BY-ND only the copyright > holder (the Foundation) has the rights to modify them. A forkable > license like for instance CC-BY-SA would solve this issue. Global > registering of the openEHR trademark would keep any derivates to be > branded as ?openEHR?. > > CC-BY-SA (for artefacts): > > ?Commercial implementers might avoid using CC-BY-SA artefacts because > the license requires any /published/ modifications of the work to be > licensed using the same license. This might lead implementers to > believe the license would require them to license their entire > software product as CC-BY-SA. There are several examples of CC-BY-SA > works being used in copyrighted works, such as Wikipedia articles > being used in newspapers, but this is probably reliant on a benign > licensor, which any normal commercial company can?t rely 100% on. The > way I see it, this problem could be solved in one of two ways: > > oUse the CC-BY license, which retains the attribution clause, but > doesn?t require any derivative works to use the same license. This has > the disadvantage of enabling proprietary tweaking of archetypes, which > could potentially ruin interoperability. > > oRetain the CC-BY-SA license, but add an explicit clause that allows > all implementers to use artefacts in closed-source, proprietary > products with any license they like. Artefacts published by > themselves, as standalone archetypes, templates or terminology sets > would still be bound by the ShareAlike clause. This is supported by > Creative Commons via the CC+ <https://wiki.creativecommons.org/CCPlus> > protocol. > > I realise these issues will ultimately be decided by the board of the > openEHR Foundation, but if the community can come to some kind of > consensus on this issue I would hope it?d send them a strong signal. > > Kind regards, > *Silje Ljosland Bakke* > > Coordinator, National Editorial Board for Archetypes, National ICT Norway > Adviser, R&D dept, E-health section, Bergen Hospital Trust > > Tel. +47 40203298 > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/98dfc483/attachment.html>
Archetype Naming proposals - do we need V0?
Hi Ian and Sebastian, The rule figured by Sebastian and the explanation by Ian looks very clear, thank you. But we will need to additional rule/guide to make it clear what is 'major' or 'minor', in the next step. For example, if the archetype was converted from ADL 1.4 to 1.5(or later), is this minor change or major change? ADL conversion may break compatibility for machine readability, but not change in clinical semantics. If an archetype was changed to be semantically incompatible, I think they should not be assigned for same archetype id. regards, Shinji 2014-10-02 1:16 GMT+09:00 Ian McNicoll : > Hi Shinji, > > For clarity ... > > CKM 'revisions' have nothing to do with the official openEHR > major.minor.path numbers. They are an internal format to do with the local > workflows inherit in openEHR. We have discussed changing CKM 'revision' to > something else to make this clearer. > > The official major.minor.patch number proposals are intended to be neutral > to the use of CKM or any other repository tool, even the use of a simple Git > repo, and make no assumptions about how the assets are organised within that > repo e.g a git-based repo may have a quite different Trunk/branching method > and use branch names/ tags to handle internal workflow. > > The aim of the openEHR major.minor.patch scheme is to ensure that where an > archetype is used outside of a repo, in tooling or in applications, that the > consumer can be very confident about the exact provenance of the archetype > and especially its stability. > > So ignore what CKM does internally, that is not important in this context. > In the future each archetype in CKM (and we hope other controlled repos) > will also label every asset and version of the asset using major.minor.patch > -XX + build, alongside what ever local internal versioning scheme they > require. > > Ian > > On 1 October 2014 17:00, Sebastian Garde > wrote: >> >> >> On 01.10.2014 17:02, Shinji KOBAYASHI wrote: >> >> Hi Ian, >> >> I would prefer https://github.com/flazz/semver/ , but not explain :) >> CKM shows archetype revision history tree, but the version is not changed. >> For example, openEHR-EHR-OBSERVATION.blood_pressure version has been >> kept 1 in these years, but it has 26 revision up. >> I think it is non-sense to change version by each revision commit, but >> meaningful change should be reflected to the version number, such as >> adding item, fixed typo, translation to other language completed. >> >> Hi Shinji, >> >> With the new revision rules a la SemVer we now have: >> >> The major version would change with an incompatible change (=the current >> v1, v2, etc identifier) >> The minor version for a compatible change which could change the meaning >> even if only slightly >> The patch version for e.g. fixing a typo in a translation. >> >> There are some grey areas, but the intention is clear I think. >> In CKM, you can do this with the new revision rules. CKM will suggest a >> new revision number based on this general idea. >> In any case you can always go higher - if you think a patch change is so >> significant because of the wording that has changed, it can also be a minor >> (or even major) version increase, i.e. instead of going from v1.0.0 to >> v1.0.1, you go to v1.1.0 >> >> To take the example of the BP archetype that you mention: >> The archetype was published in Rev 16 in 2009. >> Since then it has encountered several more changes to it like adding a >> couple of translations. >> None of these would be a breaking change to my knowledge. So, in the old >> rules it just remains v1. >> With the new revision rules, the archetype would have been published as >> v1.0.0 in 2009 and would now maybe be v1.2.4 (or whatever) - which means it >> had a number of patches and 2 minor version changes in total, none of them >> backwardly incompatible. >> >> Is this the kind of stuff you are missing? If so, this is exactly what the >> revisioning rules are there for. >> Cheers >> Sebastian >> >> >> >> Shinji >> >> 2014-10-01 23:05 GMT+09:00 Ian McNicoll : >> >> Hi Shinji, >> >> Github is your friend - see https://github.com/npm/node-semver >> >> but I agree, it is tricky. >> >> However it is simply not possible to manage the transition between stable >> and published archetypes safely by just using numbering alone. We need to >> very explicitly flag that unstable state so that it can be parsed safely - >> this is what the '-' gives us. We did look at all sort of numbering >> schemes >> and alternatives to Semver but eventually came back to the view that this >> is >> pretty well how it has to work. One big advantage of sticking with Semver >> is >> that we can take advantage of work like the NPM parser, apart from the >> >> The 'exclusive revision history' (if I understand you correctly) comes >> from >> the Build identifier, identified by a '+' >> >> So an unstable archetype may be >> >> v1.0.1-unstable+145567345 >> >> and after some internal authoring or reviewing goes
Archetype Naming proposals - do we need V0?
Sorry, I have misused "exclusive" to "explicit". It is explicit mistake. much sorry to confusing you. Shinji ashamed. 2014-10-02 0:02 GMT+09:00 Shinji KOBAYASHI : > Hi Ian, > > I would prefer https://github.com/flazz/semver/ , but not explain :) > CKM shows archetype revision history tree, but the version is not changed. > For example, openEHR-EHR-OBSERVATION.blood_pressure version has been > kept 1 in these years, but it has 26 revision up. > I think it is non-sense to change version by each revision commit, but > meaningful change should be reflected to the version number, such as > adding item, fixed typo, translation to other language completed. > > Shinji > > 2014-10-01 23:05 GMT+09:00 Ian McNicoll : >> Hi Shinji, >> >> Github is your friend - see https://github.com/npm/node-semver >> >> but I agree, it is tricky. >> >> However it is simply not possible to manage the transition between stable >> and published archetypes safely by just using numbering alone. We need to >> very explicitly flag that unstable state so that it can be parsed safely - >> this is what the '-' gives us. We did look at all sort of numbering schemes >> and alternatives to Semver but eventually came back to the view that this is >> pretty well how it has to work. One big advantage of sticking with Semver is >> that we can take advantage of work like the NPM parser, apart from the >> >> The 'exclusive revision history' (if I understand you correctly) comes from >> the Build identifier, identified by a '+' >> >> So an unstable archetype may be >> >> v1.0.1-unstable+145567345 >> >> and after some internal authoring or reviewing goes to >> >> v1.0.1-unstable+35634512 >> >> The build identifier is not guaranteed to be sequential and there may well >> be breaking changes between the first and second iteration. >> >> From the developer perspective I can know exactly which build of the >> archetype I am using in my system, and that it is unstable. I would be very >> unwise to use this in any production system but may of course need it in a >> testing phase, or need to support its use within tooling. >> >> I am not wedded to -unstable , but I think you will find that if you try to >> work with some other number=based system, you always hit a problem ,and that >> some kind of pre-release signifier is required. >> >> If we agreed that openEHR would only officially support -unstable (or >> -alpha) and -rc, that would greatly simplify the parsing. >> >> Ian >> >> >> Ian >> >> >> Implementers do not have to parse what comes next >> >> On 1 October 2014 14:34, Shinji KOBAYASHI wrote: >>> >>> Hi Ian. >>> >>> I have read once SemVer, but it is still confusing about suffix. >>> especially "alpha.11 > alpha.beta > beta.1" sequence. This needs >>> tricky grammar rule to parse. >>> >>> Hi Sebastian, >>> >>> I think revision history should be exclusive, even it is unstable version. >>> >>> Regards, >>> Shinji >>> >>> >>> 2014-10-01 21:26 GMT+09:00 Ian McNicoll : >>> > Hi Shinji, >>> > >>> > Can I suggest you read the semver.org specifications? Semver is now used >>> > pretty widely in systems and tooling (including the nodeJS Package >>> > Manager >>> > NPM). We have taken the - suffix directly from those specifications and >>> > in >>> > other respcts we are now following semver exactly so there should be >>> > open >>> > source parsers out there that can be used. >>> > >>> > >>> > Semver exists because we have to treat semantic specifications >>> > differently >>> > from normal software builds. In normal software alpha, beta, pre-release >>> > and >>> > indeed the numbering chosen do not need to have any computable >>> > significance. >>> > Windows 9 is only called Windows 9 for marketing reasons ,not because it >>> > represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update >>> > may >>> > make all sorts of breaking changes but is still a Beta and appears to be >>> > only a build different from the Developer Pre-release Yosemite >>> > candidate. >>> > >>> > When we are dealing with Semantic artefacts such as APIs or archetypes, >>> > the >>> > numbering scheme and suffixes have very specific meanings and rules, to >>> > do >>> > with backward compatibility. >>> > >>> > The -suffix is necessary to make it very clear that this is a >>> > pre-release >>> > artefact and that the normal versioning rules do not apply. What comes >>> > after >>> > the suffix does not really matter and >>> > >>> > The prime responsibility we have as archetype authors is to make sure >>> > that >>> > developers know whether they are working with a stable, published >>> > archetype >>> > which has followed the versioning rules, or an unstable archetype where >>> > those rules are temporarily suspended. >>> > >>> > It is impossible to do this clearly with a numbering schema alone which >>> > is >>> > why the - suffix is well-established in SemVer and the tools which use >>> > it. >>> > >>> > In normal circumstances unstable archetypes would never be used in
Archetype Naming proposals - do we need V0?
Hi Ian, I would prefer https://github.com/flazz/semver/ , but not explain :) CKM shows archetype revision history tree, but the version is not changed. For example, openEHR-EHR-OBSERVATION.blood_pressure version has been kept 1 in these years, but it has 26 revision up. I think it is non-sense to change version by each revision commit, but meaningful change should be reflected to the version number, such as adding item, fixed typo, translation to other language completed. Shinji 2014-10-01 23:05 GMT+09:00 Ian McNicoll : > Hi Shinji, > > Github is your friend - see https://github.com/npm/node-semver > > but I agree, it is tricky. > > However it is simply not possible to manage the transition between stable > and published archetypes safely by just using numbering alone. We need to > very explicitly flag that unstable state so that it can be parsed safely - > this is what the '-' gives us. We did look at all sort of numbering schemes > and alternatives to Semver but eventually came back to the view that this is > pretty well how it has to work. One big advantage of sticking with Semver is > that we can take advantage of work like the NPM parser, apart from the > > The 'exclusive revision history' (if I understand you correctly) comes from > the Build identifier, identified by a '+' > > So an unstable archetype may be > > v1.0.1-unstable+145567345 > > and after some internal authoring or reviewing goes to > > v1.0.1-unstable+35634512 > > The build identifier is not guaranteed to be sequential and there may well > be breaking changes between the first and second iteration. > > From the developer perspective I can know exactly which build of the > archetype I am using in my system, and that it is unstable. I would be very > unwise to use this in any production system but may of course need it in a > testing phase, or need to support its use within tooling. > > I am not wedded to -unstable , but I think you will find that if you try to > work with some other number=based system, you always hit a problem ,and that > some kind of pre-release signifier is required. > > If we agreed that openEHR would only officially support -unstable (or > -alpha) and -rc, that would greatly simplify the parsing. > > Ian > > > Ian > > > Implementers do not have to parse what comes next > > On 1 October 2014 14:34, Shinji KOBAYASHI wrote: >> >> Hi Ian. >> >> I have read once SemVer, but it is still confusing about suffix. >> especially "alpha.11 > alpha.beta > beta.1" sequence. This needs >> tricky grammar rule to parse. >> >> Hi Sebastian, >> >> I think revision history should be exclusive, even it is unstable version. >> >> Regards, >> Shinji >> >> >> 2014-10-01 21:26 GMT+09:00 Ian McNicoll : >> > Hi Shinji, >> > >> > Can I suggest you read the semver.org specifications? Semver is now used >> > pretty widely in systems and tooling (including the nodeJS Package >> > Manager >> > NPM). We have taken the - suffix directly from those specifications and >> > in >> > other respcts we are now following semver exactly so there should be >> > open >> > source parsers out there that can be used. >> > >> > >> > Semver exists because we have to treat semantic specifications >> > differently >> > from normal software builds. In normal software alpha, beta, pre-release >> > and >> > indeed the numbering chosen do not need to have any computable >> > significance. >> > Windows 9 is only called Windows 9 for marketing reasons ,not because it >> > represents a breaking change. My recent Yosemite Beta 3-> Beta 4 update >> > may >> > make all sorts of breaking changes but is still a Beta and appears to be >> > only a build different from the Developer Pre-release Yosemite >> > candidate. >> > >> > When we are dealing with Semantic artefacts such as APIs or archetypes, >> > the >> > numbering scheme and suffixes have very specific meanings and rules, to >> > do >> > with backward compatibility. >> > >> > The -suffix is necessary to make it very clear that this is a >> > pre-release >> > artefact and that the normal versioning rules do not apply. What comes >> > after >> > the suffix does not really matter and >> > >> > The prime responsibility we have as archetype authors is to make sure >> > that >> > developers know whether they are working with a stable, published >> > archetype >> > which has followed the versioning rules, or an unstable archetype where >> > those rules are temporarily suspended. >> > >> > It is impossible to do this clearly with a numbering schema alone which >> > is >> > why the - suffix is well-established in SemVer and the tools which use >> > it. >> > >> > In normal circumstances unstable archetypes would never be used in >> > production systems. >> > >> > Ian >> > >> > >> > On 1 October 2014 13:04, Shinji KOBAYASHI wrote: >> >> >> >> Hi Ian, >> >> >> >> I prefer V0, because it would be easier to adopt for other developers >> >> who do not know openEHR well. >> >> For parser implementation, 1.0.0-unstable is not a good
