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, R&D dept, E-health section, Bergen Hospital Trust > > Tel. +47 40203298 > > > > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://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 > -- 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/0b423b40/attachment.html>
