Erik,
thanks for summarising this. I still have the same position as you, that
CC-BY is the correct approach. I have not had the time to study the
licences + all related openEHR posts + all related web resources in
line-by-line detail, but I have yet to see the only thing that might
convince me that CC-BY-SA is needed, which is a list of one or more
concrete cases that the community knows it wants to support, that are
prevented by using only CC-BY rather than CC-BY-SA. I think that the key
things we need to preserve (with respect to archetypes, & templates) are:
* A - allowing an entity or individual to create a private archetype
or template (it is all the same thing in ADL 1.5 anyway). This is
clearly needed for
o purposes of private research
o purposes of local use, e.g. hospital-authored and -used
templates
o commercialisation of equipment whose data may be described
by templates
o building of application and other software based on
archetypes and templates that may or may not be published openly
* B - preventing an entity or individual from patenting or otherwise
'occupying' part of the archetype / template space, i.e.
preventing others from authoring (nearly) the same archetype or
template by their own means.
o this point is roughly equivalent to the problem of patented
software, which is by and large not an accepted practice
(see http://en.wikipedia.org/wiki/Software_patent).
* C - encourage openness, cooperation and innovation
o note that, as with other technology, the latter might be
best encouraged in some circumstances by private competition
rather than single open source efforts.
CC-BY-SA would seem to prevent all cases of the point A above, where the
artefact in question was /derived from/ some openly published artefact.
It might technically prevent B, but B isn't likely to be supportable
even with CC-BY for the same reason as software patents not being widely
accepted. C is not a function of the licence, it is a function of the
technology, formalisms, governance mechanisms, and general health of the
community.
The words 'derived from' are the magic words, and on the wiki page, I
distinguished between two kinds of derivation, namely 'semantic' and
'generated'. The first, in archetype-land means archetypes and templates
derived from previously existing archetypes and templates. There are 3
forms of this: specialisations, new versions and new revisions. Note
that in ADL/AOM 1.5, a template is a kind of specialisation of a
template or archetype. These semantic 'derivations' are equivalent to
programmers creating new classes based on existing classes (via the
inheritance relationship) or modifications of existing classes (e.g. bug
fixes, enhancements, usually provided as logical 'patches'). To my
knowledge, commercial-friendly pen source software licences (i.e.
non-viral ones) allow A above for software, and have no effect on B or C.
The other kind of 'derivation' is a hand- or machine-generation of some
different kind of artefact such as a screen form, XML schema etc, from
an archetype or template. Firstly, I don't know whether this kind of
'derivation' qualifies as 'derivation' in the sense of licences like
CC-BY, since the new artefact is not of the same kind as the old, but if
this is ambiguous, we certainly don't want to use CC-BY-SA, since we
certainly do want to allow commercial use of such generated artefacts. I
also don't know whether the generated or hand-built output artefact
could be patented, preventing another person creating the same thing by
a different means (probably some aspects could, if sufficiently
innovative), but a commercial company that uses patents might try to
patent the generator/generating software or algorithm. I think it is
more likely that they would just use normal legal means to prevent
piracy, and sell it normally. From my point of view, even if we don't
agree with such behaviour (I don't), it is not up to openEHR to try and
prevent it, and the fact that CC-BY-SA would prevent perfectly
reasonable commercial behaviour means it should not be used.
I also agree that modified open source licences are to be avoided at all
costs, because once you change a licence, the accepted legal
interpretation (often created by experts & knowledgeable amateurs over
some years) goes out the window, and you don't really know what the
meaning of the licence is.
- thomas beale
On 02/06/2010 11:15, Erik Sundvall wrote:
> Hi David and others!
>
> I have added a section for summaries of discussions to the bottom of
> the page at
> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal
>
> The current version of the text is also included below:
>
>
> Summary of views by Erik Sundvall (preferring CC-BY)
>
> There has been mail discussions on (and off) the mailinglists
> regarding what license to use for content models (exemplified above
> by openEHR.org archetypes, templates, archetype-based queries).The
> concrete suggestion from the openEHR foundation board is tu use
> CC-BY-SA with some homegrown additions. In my view the argument right
> now boils down to:
>
> * The main difference between CC-BY and CC-BY-SA is that CC-BY-SA
> in addition to the CC-BY also adds the requirement that derived
> works that are distributed must be distributed under an open
> license. The board now for some strange reason wants to use
> CC-BY-SA with a loosely formulated addition that derived works
> "do not have to be openly distributed". I have not heard any
> reasonable motivation what this would gain compared to just
> using CC-BY from the beginning. In open source communities
> homegrown additions to (or modifications of) licenses are known
> to be potential problem sources. CC-BY and CC-BY-SA (without
> homegrown additions) have been scrutinized by lawyers and have
> been translated and developed to fit legislation in many
> countries, it would take a lot of work to do the same with a
> homegrown addition to CC-BY-SA - and if there is no well
> motivated gain, then why not just use CC-BY in the first place?
>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20100602/6c7e9b69/attachment.html>
