Hi! ND on the specification documents is not a big or urgent problem if there are Apace 2 licenced computable artifacts like UML-files/descriptions of all classes, ADL/AQL grammars, openEHR term lists/vocabularies and other things needed for building actual systems. I believe that is already the case (or at least the intention).
In W3C and similar organizations the "ownership" and ways to influence the organization is probably a bit more clear than openEHR. As a Swede it is easy to compare the governance of openEHR to the constitutional monarchy I live in :-) A tradition-based non-elected royal family that most people kind of like and don't mind and then the real action/power lies in the elected parliament. It is just that the division of power and responsibilities is a bit more obvious in the nation than in openEHR. Is there a clear document describing the division of power between the "royal family" and the elected management board in openEHR? Having non-elected initial founders in the top of open source projects is not uncommon and often works well. The forking-possibly and many other things contribute to this working quite well, see the list at https://en.m.wikipedia.org/wiki/Benevolent_dictator_for_life for examples. However Standards-organization-thinking-people are likely less used to this kind of thinking, and this creates confusion or concern. So I'd say either clarify/modify governance or make licences so open that concerns about governance become irrelevant. The potential confusing effect of what SA (share alike) on the archetypes legally means for some kinds of use inside non-open-source systems is another, probably more burning issue that has already been discussed, I'll try to avoid that thread right now. //Erik Sundvall P.s. David Ingram is very nice and fitting in the role of a founding king, don't you think? ;-) måndag 7 september 2015 skrev Thomas Beale < thomas.be...@oceaninformatics.com>: > > ND = No Derivatives ad is the Creative Commons of what W3C has in their > licence <http://www.w3.org/Consortium/Legal/2015/doc-license>. It's just > designed to prevent anyone republishing altered versions of the > specifications *as the original specifications *- in other words forked > publishing, which would create real problems for obvious reasons. > > Probably we do want to allow the forking of the specifications into some > new specifications, i.e. with new names and identifiers, that clearly > cannot confused with the originals, and the ND provision > <http://creativecommons.org/licenses/by-nd/4.0/>I believe would prevent > this. > > I am not sure what the best replacement is though - it's quite important > that a specification with the title 'openEHR EHR Information Model' and > version xyz really is only one document, and that no modified versions of > that can masquerade as that thing. > > W3C achieve this with a custom copyright notice (see above). We probably > want a different approach. I don't personally have time to research this > but ideally we want a licence that does the following for the > specifications: > > - requires attribution with all replublishing, sharing > - prevents republishing in altered form with same document title, id, > and also publisher i.e. 'openEHR' > - but allows normal forking into artefacts that are clearly different > > - thomas > > On 07/09/2015 06:48, Bert Verhees wrote: > > The ND on the specs, there must be a kind of protection. Brand protection > could work, but must be registered in all countries of the world. > > You see the same problem at RFC's, they solved it like this, you cannot > change them and publish them under the same name. > In the case of RFC a changed version gets a new number. > > I don't know what it takes to make an RFC of something and if it would be > appropriate for OpenEHR. > > http://www.rfc-editor.org/ > > > -- Sent from mobile.
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
