Hi Diego, I will bring this post to the attention of the Board for a more authoritative response on the copyright / licensing question. These are just my personal opinions for now though Heather, Sebastian, Silje and I have discussed many of these issues so I can think they are probably representative.
>> The copyright holder is still openEHR? Does It have something to do >> with the CC-BY-SA license? The emerging view seems to be that *any* fork of an archetype, even if it just changes local ownership (namespace in ADL2.0) should probably result in change of copyright to the new owner with attribution to the previous owner. CC is a bit vague on when new copyright should be applied however. In your case, this is a very significant change and I would expect copyright to change. >> What license was decided we should use? Did we agree in which metadata >> field should we store this? We are adding a new 'license' attribute to other_details in ADL1.4 which will become a fully-fledged attribute in ADL2 ... other_details = < ["licence"] = <"Creative Commons Attribution-ShareAlike 4.0 International License"> ["revision"] = <"0.0.1-alpha"> ["references"] = <" Derived from .... "Adverse Reaction, draft archetype, National eHealth Transition Authority [Internet]. NEHTA Clinical Knowledge Manager. Authored: 08 Nov 2010. Available at: http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.868_7(accessed Jan 16, 2012)."> ["build_uid"] = <"0043896f-d388-437e-ad46-472cb74ec56b"> ["original_namespace"] = <"com.bosca"> ["original_publisher"] = <"Bosca Enterprises"> ["MD5-CAM-1.0.1"] = <"D5C7A064A7345211256376F748D97B6B"> ["custodian_namespace"] = <"com.bosca"> ["custodian_organisation"] = <"Bosca Enterprises"> > We are in the final stages of preparing a 'beginner's guide' that explains this stuff in more detail. >> Does the author change? I would probably say no, if the clinical content is unchanged. >>Probably the source archetype will also need >> to be referenced somehow. We would expect to see that attribution in References - see above >> What else should be changed/added? In the new world, you would need to change the namespaces, particularly as creating 13606 versions are definitely 'new' archetypes. >>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". I would expect 'generated' to apply to same ref model ADLS->ADL kinds of transforms only but interesting question. @Thomas ?? >>Can the resulting ADL be publicly distributed? Yes, absolutely, as long as you do not try to re-sell the 13606 archetypes with a closed-source licence!! Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation Management Board Director, freshEHR Clinical Informatics Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 28 April 2015 at 09:00, Diego Bosc? <yampeku at gmail.com> wrote: > 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 > > _______________________________________________ > 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/20150428/8080bbdd/attachment-0001.html>
