I refloat this thread as I think I got a practical use case: I have generated a transformation from openEHR archetypes to ISO13606 archetypes. I have a couple of questions about the resulting ADL. The copyright holder is still openEHR? Does It have something to do with the CC-BY-SA license? What license was decided we should use? Did we agree in which metadata field should we store this? Does the author change? Probably the source archetype will also need to be referenced somehow. What else should be changed/added? I assume that also a 'generated' field should be added (I know ADL 2 has this as a explicit field ;) so for the moment probably the best is to store everything we can't put elsewhere in "other_details".
Can the resulting ADL be publicly distributed? 2014-10-05 23:02 GMT+02:00 Bert Verhees <bert.verhees at rosa.nl>: > Is there going to be a follow up on this discussion? > Will we here something about it? > > Bert > > > Op donderdag 2 oktober 2014 heeft Erik Sundvall <erik.sundvall at liu.se> het > volgende geschreven: >> >> Thank you Grahame for sharing the HL7 FIHR licensing experience! >> >> This actually changes the game! >> >> >> Short version: >> Whatever openEHR does will now be compared to what HL7 actually has >> allowed for FIHR. If we with openEHR are less open than FIHR, then we?ll >> need to defend that position somehow, which will be hard. For example ?Why >> do the FIHR guys trust their community, implementers and users more than >> openEHR does? What is the hidden agenda of openEHR?? >> >> >> Long version: >> Since Linkedin is not an open forum, I here post an edited and updated >> version of my contribution to that discussion. >> >> I agree there has been a lot of misunderstandings and FUD >> [http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt] regarding the >> openness of openEHR. In fact openEHR is already more open than many other >> technical standards/specifications that many companies and governments use >> without much hesitation. Regarding licensing I and others tried to explain >> some years ago that there might actually be some scenarios with CC-BY-SA >> archetypes that might be reasons for (somewhat far-fetched) fear among >> closed source vendors. >> >> Please read the following two wiki-pages including the comments below them >> if you have not already? >> >> 1. >> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal >> 2. >> http://www.openehr.org/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA >> >> ?so that we do not need to repeat too much of the discussions once again. >> There you can find the openEHR statement about the intention apply the >> SA-clause only to derived archetypes, not to other derived things. (You can >> also read my comment discussion about how the SA-clause is either contagious >> anyway or easily circumvented.) >> >> The main conflicts visible in the wiki-pages above concern the license of >> archetypes, not the specification documents (since they were under another >> kind of license by then, more ?forkable? than the current CC-BY-ND). >> >> Some FUD/fears might be counter-argumented by the fact that, even if >> CC-BY-SA for archetypes could theoretically be interpreted as imposing SA on >> some other downstream artifacts than archetypes, (proprietary software for >> example) this would never become a problem unless the copyright owner >> (openEHR) wants to take somebody to court, and they (the openEHR board?) >> clearly says in writing that _they won't_ for the uses they have described >> in the wikipages linked above. (Also as Grahame pointed out, it would be >> self-destructive.) To use openEHR-copyrighted CC-BY-SA archetypes you only >> need to trust openEHR the same way you need to trust other organizations you >> depend on. Once the openEHR foundation has more understandable governance >> (and is accountable to members, or something similar) then that will be a >> bit easier. >> >> >> My personal conclusion of the licensing debate at the time (2011) was that >> there was no point in continuing it until there was another board elected >> that could/wanted to weigh Sam?s arguments against other people?s arguments, >> thus I focused on other things. I do think that Sam?s intentions/fears (e.g. >> to avoid hostile lock-in of archetype design-space) were understandable all >> through this, but that he was trying to use the wrong tool (a homegrown >> modification of CC-BY-SA) to achieve that goal. >> >> Now, a probably worse problem is that by using CC-BY-SA for the >> international CKM archetypes for several years, openEHR has set an example >> that others follow in other CKM equivalents where the copyright owner could >> instead be a national organization (e.g. NETHA), a care provider or a >> company. (Perhaps even a company that gets bought by a ?copyright/patent >> troll? that makes a mess by unjustified lawsuits.) >> >> If everybody used something as free as CC-BY or CC-0 for archetypes etc. >> it would not matter if the copyright-owner could be trusted over time or >> not. You would then not need to convince organizations to "please assign the >> copyright to openEHR" before sharing your works with the world (e.g. on the >> openEHR CKM). But a company might have a hard time understanding why their >> published/shared archetypes should be either copyright-assigned to openEHR >> or released under CC-BY or CC-0, when the openEHR foundation itself uses >> CC-BY-SA. Why share the company?s archetypes with no (SA-)strings attached >> when the foundation has (SA-)strings attached to their gifts? [Computer nerd >> clarification: I here mean strings as in the saying ?no strings attached?, >> not strings in the ?datatype? sense of the word :-)] >> >> >> >> Now let?s switch subject to from archetypes to the ND-clause on the >> technical specification documents, I think CC-BY-ND is more restrictive >> regarding forking than the previous homegrown openEHR licenses were (that >> allowed relicensing under other licenses). Thus the fact that forking has >> occurred previously does not say anything about the current "forkability" of >> the specs. The fact that openEHR did not make a lot of fuzz regarding the >> previous forks might however say something positive 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 >> > > > -- > This e-mail message is intended exclusively for the addressee(s). > Please inform us immediately if you are not the addressee. > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
