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 > <javascript:_e(%7B%7D,'cvml','erik.sundvall at lio.se');> > http://www.lio.se/itc/ & http://www.lio.se/testbadd > LiU: erik.sundvall at liu.se > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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.* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141005/a44b718e/attachment.html>
