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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/af556f4a/attachment-0001.html>
