Licensing of specs and artifacts
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
Licensing of specs and artifacts
The current proposed AOM 2 meta-data can be seen here http://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1422971258847_792963_30335. Notes: * One thing we added due to CIMI, which we think is globally applicable is 'conversion_details' in RESOURCE_DESCRIPTION. Typically, an archetype with is_generated = true will have these conversion_details set. This should take care of the 13606 conversion example. * See also ip_acknowledgements, which is how we will put in acknowledgements for e.g. SNOMED, LOINC etc. * The model doesn't yet include any changes corresponding to Silje and others ideas about a better model of translator details. The current test example of an archetype with full meta- https://github.com/openEHR/adl-archetypes/blob/master/ADL2-reference/features/meta_data/openehr-test_pkg-WHOLE.full_meta_data.v0.0.1.adlsdata is as follows. archetype (adl_version=2.0.5; rm_release=1.0.2; generated) openehr-test_pkg-WHOLE.full_meta_data.v0.0.1 language original_language = [ISO_639-1::en] description original_author = [name] = Thomas Beale thomas.beale at oceaninformatics.com [organisation] = Ocean Informatics http://www.oceaninformatics.com details = [en] = language = [ISO_639-1::en] purpose = This archetype demonstrates the use of governance meta-data. use = This archetype should be used on a clear day with no wind. misuse = This archetype should not be used around children or dogs. keywords = governance, test original_resource_uri = [resource A] = Some resource available in the English language http://aaa.bbb/path/to/resource [resource B] = Some other resource available in the English language http://aaa.bbb/path/to/resource lifecycle_state = unmanaged other_contributors = Marcus Aurelius marcus at aurelius.net, Augustus Caesar augustus at caesars_palace.net original_namespace = org.archetypes-r-us original_publisher = Archetype R Us custodian_namespace = org.openehr custodian_organisation = openEHR Foundation *licence = Creative Commons CC-BY https://creativecommons.org/licenses/by/3.0/* copyright = Copyright (c) 2014 openEHR Foundation resource_package_uri = http://www.openehr.org/ckm/path/to/package *ip_acknowledgements = ** **[loinc] = This content from LOINC? is copyright ? 1995 Regenstrief Institute, Inc. and the LOINC Committee, and available at no cost under the license at http://loinc.org/terms-of-use;** **[snomedct] = Content from SNOMED CT? is copyright ? 2007 IHTSDO ihtsdo.org** **** **conversion_details = ** **[source_model] = CEM model xyz http://location.in.clinicalelementmodels.com** **[tool] = cem2adl v6.3.0** **[time] = 2014-11-03T09:05:00** **** *references = [1] = Barthel Scale http://en.wikipedia.org/wiki/Barthel_scale [2] = Barthel Index, the Internet Stroke Center http://www.strokecenter.org/wp-content/uploads/2011/08/barthel.pdf [3] = O'Sullivan, Susan B; Schmitz, Thomas J (2007). Physical Rehabilitation, Fifth Edition. Philadelphia, PA: F.A. Davis Company. p. 385. other_details = [regression] = PASS On 28/04/2015 13:26, Ian McNicoll wrote: 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] =
Licensing of specs and artifacts
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!! It?s actually a little more strict than that; the SA (ShareAlike) clause in the Creative Commons BY-SA licence (which all the openEHR archetypes are licensed under) mandates that any derivative works are licensed under the same (or a compatible, but for practical purposes there aren?t any , see https://creativecommons.org/compatiblelicenses) licence, ie the CC-BY-SA licence. Regards, Silje From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Ian McNicoll Sent: Tuesday, April 28, 2015 2:26 PM To: For openEHR technical discussions Subject: Re: Licensing of specs and artifacts 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.commailto: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.commailto: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.nlmailto: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.semailto:erik.sundvall at liu.se het volgende geschreven: Thank you Grahame
Licensing of specs and artifacts
*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/20141003/9c241e12/attachment.html
Licensing of specs and artifacts
Thanks Silje, that you bring this very important subject under attention. It was already under attention recently on a LinkedIn discussion, but I am afraid it did not reach the right people. I do agree with your point of view, so there is not much discussion, there is only one small remark. I don't see any point in retaining the CC-BY-SA license, with extra clause. First, CC-BY-SA prevents the secret proprietary use of OpenEHR-archetypes, in industry this can be a reason not to use OpenEHR. Except from that, CC-BY-SA is not by everyone understood and is a source of FUD (Fear, Uncertainty, Doubt), even with extra clause, it will remain a source of FUD. For information the link to the LinkedEhr discussion, I hope it works https://www.linkedin.com/groups/Membership-144276%2ES%2E5909661200660054019?trk=groups_most_popular-0-b-ttlgoback=%2Egde_144276_member_5909661200660054019%2Egmp_144276 Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: Hi everyone, In light of the recent re-licensing of FHIR http://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meeting http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I?d like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivatives http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alike http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I?m bound to have forgot some issues: CC-BY-ND (for specs): ?Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as ?openEHR?. CC-BY-SA (for artefacts): ?Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any /published/ modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can?t rely 100% on. The way I see it, this problem could be solved in one of two ways: oUse the CC-BY license, which retains the attribution clause, but doesn?t require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. oRetain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it?d send them a strong signal. Kind regards, *Silje Ljosland Bakke* Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 ___ 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/20141002/98dfc483/attachment.html
Licensing of specs and artifacts
For information the link to the LinkedEhr discussion, I hope it works Of course, this should be: LinkedIN ;-) (sorry David) Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: Hi everyone, In light of the recent re-licensing of FHIR http://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meeting http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I?d like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivatives http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alike http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I?m bound to have forgot some issues: CC-BY-ND (for specs): ?Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as ?openEHR?. CC-BY-SA (for artefacts): ?Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any /published/ modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can?t rely 100% on. The way I see it, this problem could be solved in one of two ways: oUse the CC-BY license, which retains the attribution clause, but doesn?t require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. oRetain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it?d send them a strong signal. Kind regards, *Silje Ljosland Bakke* Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 ___ 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/20141002/26c7bb0b/attachment-0001.html
Licensing of specs and artifacts
Hahaha, it's good you always have LinkEHR in mind ;-) By the way, this is certainly an old and recurring topic. I have checked that there were already discussions back in 2009, so probably we are going to repeat things already commented. I will talk about artefacts (archetypes). The first thing to solve in my opinion is to agree on what does derivative work mean for an archetype. Is just modified archetypes? Auto-generated data base schemas, validation schematron or other technical artefacts? Documentation describing the archetype? I would love to say that only the first case applies, but let's thing in an example. Which is the license for a movie you make from a CC-BY-SA book? It is for sure a derivative work, and the Title 17 Section 101 of the Copyright Act of the United States says it very clear: A derivative work is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a derivative work. ( http://www.law.cornell.edu/uscode/text/17/101) Given that definition I don't think a technical transformation of an archetype is a different case. So yes, I'm not a lawyer, but I would say that fears of implementers of commercial products using openEHR archetypes are reasonable if the the CC-BY-SA license is applied as is. David 2014-10-02 8:31 GMT+02:00 Bert Verhees bert.verhees at rosa.nl: For information the link to the LinkedEhr discussion, I hope it works Of course, this should be: LinkedIN ;-) (sorry David) Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: Hi everyone, In light of the recent re-licensing of FHIR http://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meeting http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I'd like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivatives http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alike http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I'm bound to have forgot some issues: CC-BY-ND (for specs): ? Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as openEHR. CC-BY-SA (for artefacts): ? Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any *published* modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can't rely 100% on. The way I see it, this problem could be solved in one of two ways: o Use the CC-BY license, which retains the attribution clause, but doesn't require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. o Retain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it'd send them a strong signal. Kind regards, *Silje Ljosland Bakke* Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47
Licensing of specs and artifacts
At the end of the day, I don't really care what licence is used for these things in openEHR - maybe the community should just vote. The long debates from the past are summarised here http://www.openehr.org/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA and here http://www.openehr.org/wiki/display/oecom/openEHR+Transition+Feedback+Page. This page http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal contains one attempt I made to state the requirements for each kind of openEHR IP. Nevertheless, here are some new thoughts, based on a review of CC-BY-SA 4.0 I think the key things to remember in resolving this are how the various artefacts get used, which helps figure where 'adaptation' actually exists. I can think of the following: * archetype = template = software application o the simplest standard practice o this is USE not ADAPTATION * archetype = specialise = template = software application o the next simplest standard practice o this is USE not ADAPTATION * archetype = software application o not a great idea in general - it means that the 'archetypes' are not really maximal re-usable data sets, but something like predefined templates. However, someone is bound to do this, and produce a good product from it. o this is USE not ADAPTATION * archetype = forking = modification = templating = software application o Result: probably non-interoperable data; but may occur for pragmatic reasons, e.g. openEHR is too slow to make fixes to the archetype. o this is ADAPTATION According to the CC-BY-SA 4.0 licence text only the last of these paths means that the final software or other result is an 'adaptation' of the original archetype, which means that the CC-BY-SA license applies, IF YOU PUBLICLY SHARE THE ARTEFACT. Here is relevant licence text from the CC site https://creativecommons.org/licenses/by-sa/4.0/legalcode (my bolding): 1. *Adapted Material*means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is *translated, altered, arranged, transformed, or otherwise modified *in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 2. *Share*means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. * 3b ShareAlike*. 1. In addition to the conditions in Section3(a) https://creativecommons.org/licenses/by-sa/4.0/legalcode#s3a, if You Share Adapted Material You produce, the following conditions also apply. 1. The Adapter's License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. In contrast to what David says, I don't believe a technical transformation of an archetype, say into some kind of XML or JSON would be a modification of the original artefact, it's just a downstream conversion, like rendering an original document written in MarkDown or Wikimedia-markup into HTML. That's what Wikipedia and Github and hundreds of other sites already do, and that rendering is not regarded as an 'adaptation' to my knowledge. So I think the real legal question is about the last path above - forking archetypes, modifying the (copy of the) original and then doing something with that, followed by public sharing. If you fork an archetype, build software from that, and sell the software you are not sharing, according to the CC definition above. Thus, I don't know that CC-BY-SA is actually problematic, unless it turns out that either technical transformation, including technical use via compilation into software, constitutes 'adaptation'. HOWEVER... on reading the non-legal
Licensing of specs and artifacts
2014-10-02 10:03 GMT+02:00 Thomas Beale thomas.beale at oceaninformatics.com: I think the key things to remember in resolving this are how the various artefacts get used, which helps figure where 'adaptation' actually exists. I can think of the following: - archetype = template = software application - the simplest standard practice - this is USE not ADAPTATION - archetype = specialise = template = software application - the next simplest standard practice - this is USE not ADAPTATION - archetype = software application - not a great idea in general - it means that the 'archetypes' are not really maximal re-usable data sets, but something like predefined templates. However, someone is bound to do this, and produce a good product from it. - this is USE not ADAPTATION - archetype = forking = modification = templating = software application - Result: probably non-interoperable data; but may occur for pragmatic reasons, e.g. openEHR is too slow to make fixes to the archetype. - this is ADAPTATION According to the CC-BY-SA 4.0 licence text only the last of these paths means that the final software or other result is an 'adaptation' of the original archetype, which means that the CC-BY-SA license applies, IF YOU PUBLICLY SHARE THE ARTEFACT. Just to be clear, I repeat that that is exactly what I would like to interpret. But if I read the legal texts trying to be objective (and again, not being a lawyer!) it is normal that doubts arise. If I generate a validation software that includes validation rules from the archetype constraints, that is arguably an adaptation, not just a use. And it is also important to note that if you sell a software you are also publicly sharing it. Publicly share does not imply for free, but outside of a personal use. I fully support the comments of Grahame. Probably the solution is to go just for the simpler option and don't worry about what others do with their own business. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/b357fa49/attachment.html
Licensing of specs and artifacts
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
Licensing of specs and artifacts
Hi everyone, In light of the recent re-licensing of FHIRhttp://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meetinghttp://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I'd like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivativeshttp://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alikehttp://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I'm bound to have forgot some issues: CC-BY-ND (for specs): ? Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as openEHR. CC-BY-SA (for artefacts): ? Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any published modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can't rely 100% on. The way I see it, this problem could be solved in one of two ways: o Use the CC-BY license, which retains the attribution clause, but doesn't require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. o Retain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it'd send them a strong signal. Kind regards, Silje Ljosland Bakke Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5e2d6c81/attachment-0001.html
