Editor note: I have created this page after talking with Sam to try and straighten out the CC-BY-SA v CC-BY debate. This page tries to state the true intention of the white paper, which is unclear in the white paper as currently published. The first section contains the redacted proposal; all analysis and opinion should be added to the second section.

- thomas beale, 12 Sep 2011

The openEHR CC-BY-SA proposal

Please DO NOT ADD ANY OPINIONS or COMMENT in this section!!! Use the next section.

Background

The CC-BY-SA 3.0 unported license.

Key clauses:

• "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.
• "Distribute" means to make available to the public the original and copies of the Work or Adaptation, as appropriate, through sale or other transfer of ownership.
• Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Key condition of the CC-BY-SA 3.0 licence pertinant to openEHR proposal:

• specific conditions are waivable if permission is obtained from the copyright holder. See both the CC-BY-SA licence text (at the bottom) and the CC FAQ on this.

The openEHR CC-BY-SA licence

The Design Intent

The idea is to prevent a third party creating a specialisation of a openEHR.org Archetype or Template that is then licenced in such a way so that anyone a) using it has to pay fees and/or b) independently developing the same archetype might receive a claim of breach of copyright, patent or other legal infringement.

Definitions

'Archetype' and 'Template' mean any artefact that is a direct expression of any release of the openEHR AOM specifications or the de fact .oet template specification, including:

• any archetype or template expressed in ADL 1.4, 1.5 or any later release of ADL
• any archetype or template expressed in the XML serialised form of the AOM, i.e. the form generally known as the 'XML format of archetypes'
• any archetype or template expressed in any other serialisation of an AOM structure, e.g. JSON, a different kind of XML
• any template expressed in the de fact .oet file format

'Derived' archetype / template means an archetype that is:

• a specialisation of an existing archetype or template, in the sense of 'specialisation' as supported by the archetype tools, and as described in the ADL (1.4 and 1.5 ) and AOM (1.4 , 1.5 ) specifications (particularly the ADL 1.5 specification) - i.e. another archetype or template, i.e.
  • that mentions in its 'specialisation parent' clause the identifier of any openEHR.org archetype or template, or a specialised archetype ultimately derived by the same relationship, from an openEHR.org archetype or template
  • and 'compiles' with a reference compiler, i.e. that is a technically valid specialisation;
• regardless of how built - by tools, by hand, or by generation by a tool
• BUT NOT any other kind of generated product, such as
  • program code
  • a UI form
  • an XML schema
  • or any other non-archetype artefact

The Licence

• What form of the license would be used:
  • the CC-BY-SA 3.0 (ported or unported?) with a waiver exception for 'other generated products' as defined above, to be created, distributed and licensed in any way the authoring party wishes.
• Applicability:
  • to archetypes and templates developed on or donated to and maintained by openEHR.org
  • and by extension, due to the way CC-BY-SA works, to all derived archetypes and templates whose specialisation parent is one of an openEHR.org CC-BY-SA-licensed archetype or template
    • e.g. this could be archetypes in national repositories.
  • But due to the waiver, not to downstream generated artefacts.

• Note that no statement is being made about copyright of derived archetypes or templates.

Analysis & Opinion

PLEASE ADD YOUR OPINIONS HERE, ATTRIBUTED

by Diego Boscá:

• Is an XML instance following an archetype a derivated work?
• What about a mindmap? and OWL?
• is a specialization of an archetype really a derivation? I think we are trying to override the real meaning of derivation. If we are strict every archetype is a specialization of the root concept (e.g. blood_pressure is a specialization of OBSERVATION). Are we just prohibiting that nobody can close an specialized archetype?
• what about an specialization in other format?
• In my interpretation, the 'key condition' of the CC-BY-SA 3.0 stated before has to be signed per archetype (and by all the authors of the archetype) which would made that impractical at best

T Beale feedback on above questions:

• XML instance data would not be a derived work, nor a mindmap. An OWL serialisation might be possible, if so, it would be.
• on the definition of 'derivative work', I agree it is difficult, that is why it is spelled out in detail above. Blood pressure is not a 'specialisation' of Observation in the technical sense described by the documents, so I don't think any danger exists here.
• regarding the waiver, it would have to be signed by the copyright owner. If there are multiple copyright owners, then this will get difficult. But a lot of things get difficult in that situation, that is why open software etc is generally copyrighted to a trusted open organisation, like FSF, Apache or whomever.

by Thomas Beale after a long discussion with Erik Sundvall, we came up with the following points:

• we realised that the definition of a 'derived archetype/template' needs to be nailed down further, to say that it includes only technically valid, i.e. compiling artefacts (which would require a definition of 'compiling'). This means that copies of CC-BY-SA archetypes that have e.g. different at-codes or whatever would not compile with respect to published openEHR.org ones, would not be subject to the licence;
• waiver problems: it would appear that if the waiver could only be created by the copyright holder. So let's say a national e-health organisation like Nehta (Australia) or SocialStyrelsen (Sweden) creates some specialisations of openEHR.org archetypes; these archetypes then get the CC-BY-SA licence. So far so good - everything stays open. But to enable industry users to freely generate downstream non-archetype artefacts, the waiver part has to be in place. Now Nehta, SocialStyrelsen etc have to put their own waiver in... OR is the openEHR waiver still in place?

The same license would work for all archetypes - i.e. it would be used by everyone. The only reason to have the license is to make it possible for people to retain copyright and give appropriate permissions for use.

Sam

Heather Leslie: The text in the license states: "Waiver — Any of the above conditions can be waived if you get permission from the copyright holder."  So downstream users cannot 'loosen' the original conditions of license without permission from the original copyright holder.

• the other main thread of discussions is about the types of threat - i.e. parties trying to lock everyone else out of a part of the archetype space by 2 possible strategies:
  • patenting: this is long, hard and very expensive. We assume that only really big corporations could do this, and that they will have the legal muscle to crush any protests based on any kind of licensing and even fully copyrighted unlicenced works.

I do not believe it is possible to patent archetypes.

Sam

• • non-patent-based attempts to copyright and charge for use. Copyrighting a derived CC-BY archetype is fine.

The CC licenses are to overcome copyright restrictions - so I believe you can copyright a derived work whether it is CC-BY or CC-SA.

Sam

Heather Leslie: The CC licenses are copyright licenses. Those who want to make their work available to the public for limited kinds of uses while preserving their copyright may want to consider using CC licenses

• •  Trying to charge for its use is undoubtedly possible (but it might be hard to sell); trying to prevent someone else creating a very similar archetype independently seems pretty far-fetched - and this is the only real thing that CC-BY-SA could reasonably protect us from. So... would it help? It seems to us that it might stop some parties trying to do this, but it appears to be very difficult to do anyway. The whole world of open source CC-BY style (e.g. MIT) licensed software is proof of that, you don't hear much about e.g. MIT licensed projects being stopped because of copyright claims. If there is a part of the code with external copyright claim problems, then a reimplementation of that functionality is done.

We do want to stop that sort of thing - it could be a real mess as these artefacts may propagate very quickly.

Sam

What "sort of thing" in that long paragraph do you want to stop? //Erik Sundvall

• Erik raised the question of whether, even with a clearly stated waiver version of the licence, companies might feel nervous about writing software that contained CC-BY-SA archetypes or was based on archetypes, for fear of it infecting their code.

This is a concern we have to balance with that of commercialisation of archetypes.

Sam

I don't think you want to stop "commercialisation of archetypes" just the percieved risk of somebody "locking up design space" am I right? ("Locking of design space" is very hard to do using copyright, but in some cases possible with patents. I think we agree that an archetype would be very hard to get a solid patent on though...). //Erik Sundvall

There are legal unknowns here, but I think our conclusions are similar:

• CC-BY-SA seems only to potentially address non-patent based attempts to lock out people from a particular archetype, and this would be very hard to do anyway, even with CC-BY
• the need to include the waiver down a chain of licensed artefacts seems to complicate things unnecessarily compared to using CC-BY

I think we will need a waver with CC-BY describing when attribution is not necessary.
Sam

I am aware of having too little legal knowledge in this area. I am pursuing a RFI to the Creative Commons organisation to clarify the waiver question.

(The text above was later somewhat edited by Erik and Heather, use diff to see changes) 

The Problem of Attribution

(after discussions with Sam and Erik)

There is a worry that the BY part of CC-BY-anything requires attribution that might be practically speaking to onerous in some cases to actually do. For example, an HTML rendering of a template in a real system, where the template is derived from 30 archetypes - does the HTML form have to include attribution of those 30 archetypes, as the CC-BY would imply? It appears that as long as the original licensor specifies an acceptable means of attribution, e.g. a single URL in small print on an application startup screen, then there will be no problem.

Erik notes that the problem of having to create giant accumulating attributions was one reason for the BSD 4-part license turning into the BSD 3-part license in use today .