you see, we’re already debating whether it is or isn’t! My conclusion from having gone though all the CC legal documention over the last couple of years to determine exactly what is a ‘derivative’ or not was that CC just doesn’t apply that well to technical artifacts that have a) lifecycles and b) tooling frameworks that do source → combine → compile → deploy and similar.
We initially decided to use CC licenses for archetypes because we used them for the specifications. If we are rethinking this whole thing, we maybe should just do trademark + Apache 2 for everything, especially as even the abstract specs have computable models in them (BMM, previously UML).
I’m certainly not 100% sure about that. From what I understand those CC licenses apply to authored works that are protected by copyright like literature, music, film, etc. and those are as technical as you can get, need tooling (hardware and software) and tool chains to put them together in some kind of process, very similar to combine → compile → deploy. So the analogy, at least for me, doesn’t seem to apply here.
I see archetypes as similar authored works, that can be modified, extended, mixed, etc. and I would call that derivative work. Though if a software USES the archetype, the software isn’t derivative work, even if the software is designed to do any work to generate the derivative work: it’s the result what’s derivative. At least that’s what I understand.
For the specs themselves, I think you can see those as some kind of specific literature, though the authors and who holds the IP are different entities.
So, related to the question I asked in the original thread that referenced this one: if we create a RM package that uses/references some of the existing RM classes, I don’t think that’s derivative work, because is a reference: it doesn’t change the original thing, just uses it. Is like using the ISO 8601 date format spec: you reference to it and use it, but you don’t change the spec in any way. This is also personal interpretation. Though formal confirmation from the openEHR Foundation would be nice.
I think I see what you mean now: The Archetype Designer uses an archetype to generate an OPT, but isn’t derivative. While a medication module incorporating a set of OPTs generated from archetypes is derivative. Is that what you meant?
You are right about all the modern tools. But the difference I was getting at is there is still (mostly, with a few exceptions) a single ‘final version’, whether of a song, book or artwork. In software and information engineering, we don’t have a definitive version, we have a release cycle and multiple versions each containing (we hope) constant improvement. Whereas Taylor Swift puts out her new album and moves on to the next one. Creative Commons is all about determining and protecting rights on these kinds of artifacts. And the idea of a ‘derivative’ of such artworks is intended to say whether you have acceptably reused some copyrighted bit of music in your new mashup video. For us in the tech world, ‘derivatives’ aren’t exceptions, they’re really just ‘use’, and the norm.
That is how I (and I assume some others) have historically thought about them. But they are still constantly improved and versioned. There’s no single copy of the EHR Information Model spec you can get, in the way you can get a copy of Dorian Grey at the bookshop. And specs are increasingly generated from semi-computable and computable source files, which are directly ‘usable’ by tools.
We change our specs all the time - that’s what all the releases are. ISO is just glacially slow at that kind of process!
For the above reasons I now think that CC isn’t a great fit, even for the specifications (and I do love the whole Creative Commons project… but we need to serve our own needs as well).
@siljelb in terms of the software, yes. It’s like a audio mixing or video editing software: the software itself isn’t derivative but the result could be.
I don’t think using a template somewhere is derivative, though the template must of the time is derivative work from archetypes drive new constraints are applied on top to create the template. For instance using a template to feed CDS rules IMHO isn’t derivative work, is usage. The difference between that and the archetype-template relationship is the latter uses the same base elements and had the same goal, and the template can’t exist without the archetype. Though the CDS rule had logic that can live independently from templates and archetypes, and using them is just a design decision. I know there is a grey area, that’s why the Foundation should clarify and formally day what’s what.
While we may or may not agree about the fitness of the CC licenses for the works in question, relicensing them is not trivial. Especially getting contributor approval would be next to impossible for archetypes. That is, unless we have a contributor license agreement (CLA) which permits relicensing, which I don’t think we do.
With that in mind, we’re likely stuck with CC-BY-SA. I would hope though that we could get away with applying a dual license or at worst a clarifying exception to the -SA clause, since the intent has never been to prohibit using archetypes in proprietary software.
Something along these lines?
For the purposes of the Creative Commons Attribution Share Alike 4.0 International License applied to openEHR information model source files, the following rule applies.
The following artefacts are not considered Adapted Material or derivative works:
Operational Templates (OPTs) generated from archetypes or templates
Flattened or compiled representations of templates
User interface definitions or forms generated from templates or OPTs
JSON schemas, XML schemas, code, or other technical artefacts automatically generated by tooling
Runtime artefacts produced by software systems using the models
Clinical data or other content created within systems that implement the models
These artefacts may be licensed and redistributed under the Apache License 2.0, and no Share Alike obligation is applied to them.
Changes to archetypes, templates, or other model source files themselves remain subject to the CC BY SA 4.0 license and must be shared under the same license.
Let me reason on that: OPTs generated are a form of aggregating what we already have, kind of a different format that expresses the same thing (semantically) as existing artifacts but do not change them. Though semantically it’s the same thing, just in a different format.
I’m really bad with analogies, though isn’t that like changing a song from WAV to MP3? It’s a different format but it’s the same song and the copyright is in the song, not in the format (though formats might have their own IP and licensing, like JSON or XML could have, or even ADL).
It’s the same with Flattened/compiler representations of templates.
Though user interface definitions is another layer that might use templates and archetypes, but it’s about the USE, it’s not the same thing semantically speaking.
A multilingual java-based EHR GUI made by company A may contain every logical and structural requirement from an archetype (compiled as java code) in order to produce nice RM instances and explain the contained archetypes to curious users.
According to the suggested SA-waivier-modification I assume this GUI could be released under any license, e.g. Apache 2.
Yes or No?
Company B later makes a program that analyses company A’s open source GUI and via reverse engineering recreates the original archetype and serialises it in an openEHR compatible ADL- or XML form that is logically equivalent to the original archetype.
Is this reverse-engineered archetype bound by openEHRs original CC-BY-SA license claims?
Yes or no?
If yes, then company A’s code was obviously SA-contagious and the wavier was not worth much as a comfort.
If no, then the CC-BY-SA of the original archetype is fairly easily circumvented (so one might just as well use CC-BY in the first place and skip all the confusing wavier and copyright assignment stuff, and use better means to fight bad copyright claims).
If it is hard to get permission to relicense some existing archetypes (e.g. because it is hard to reach contributors/authors) then adding the dual license (suggested by @siljelb) to those archetypes might be a step in the right direction.
Yes, per my “The following artefacts are not considered Adapted Material or derivative works:” list above. Does it need to be logical if it’s clearly stated?
Tbh I think this is a bit far fetched. But since the new artefact is in fact not based on the CC-BY-SA licensed artefact but on source code licensed under some other OS license, it would not be affected by the CC-BY-SA license. So no.
Sure, but why would anyone want to go through all that just to be able to publish an archetype (as an archetype and not as any of the downstream artefact mentioned in my list above) under a license other than CC-BY-SA?
I think I’ve said this before somewhere, but IMO the greatest benefit of the -SA clause (or any other copyleft license) for archetypes is that all CKMs and other repositories in the “openEHRosphere” use the same license. If one repo used GPL, another Apache2 and a third CC-BY-NC, it would create huge barriers to sharing models to the point where it just wouldn’t be worth the hassle.
(Edit: When we created the Norwegian CKM back in 2014, we did have a small discussion about which license would be the best for our purposes. It was a very short discussion, because of the -SA clause of the international CKM. If the international CKM had been CC-BY at the time, we could have ended up with GPLv3, the European Union Public Licence or something else, which could have become a huge spanner in the collaboration works)
The discussion in your link touched upon another point though; how do we handle the “attribution” clause which is part of most open source licenses including CC-BY-SA. Do every archetype need to be attributed explicitly? Or even every contributor for every archetype?
IMO it would be enough to attribute the source repository(ies) with name and URL, but the main point I guess is that this should be made explicit of our licensing information which I don’t think it currently is.
Nowadays with AI assisting in coding “go through all that” is just a matter of likely less that one day’s work in order to create a reusable tool that then in seconds can be used to go from e.g. ADL to code/software (for example template specific classes) and back to ADL for any archetype.
Somebody could argue that even reading the archetype into an object representation via Archie (then perhaps storing and then retrieving the object representation if one wants to be picky) and then serializing it again into ADL could be a variant of the above.
Thus the -SA is very easy to circumvent when downstream artifacts are not bound by -SA. I think FHIR did a smart thing with CC0 that even got rid of the attribution problems.
Trying to use license to enforce coherence is likely the wrong tool. Better tools are:
community building
openness to several use case requirements from many actors
education efforts regarding the stupidity and shortsightedness of unnecessarily forking modelling efforts
