hi
we should certainly examine the discussions you have had in FHIR-land.
The discussions were all private threads, but I can give you a summary
run down. We start with our plain english license:
* FHIR is © and ® HL7. The right to maintain FHIR remains vested in HL7
* You can redistribute FHIR
* You can create derivative specifications or implementation-related
products and services
* Derivative Specifications cannot redefine what conformance to FHIR means
* You can't claim that HL7 or any of its members endorses your derived
[thing] because it uses content from this specification
* Neither HL7 nor any of the contributors to this specification accept
any liability for your use of FHIR
Our intent here is a license for a standard: lots of commercial
companies are going to be forced to use it (eventually), and lots of
open source applications too. What can we do to make that easy? Well,
we let anyone do anything, as long as they can't grab control of the
actual spec. For FHIR, at least, that's vested in HL7, so when we
think about grabbing control, we think in terms of "from HL7".
There's another set of considerations there too: with a lot of
existing specifications, implementation guides - which are very
derivative works - are in a grey zone. In fact, my opinion is the bulk
of Australian HL7 derived standards are not ok against the HL7 license
(and lots of other IGs too...), but HL7 affiliates don't push the
issue because we want adoption. Well, they don't usually push the
issue - and if they do, it's extremely self-destructive. But we wanted
to be explicit and clear: whatever you need to do in an implementation
guide, go do it with no worry about 'surprises' later (they tend to be
expensive$$$$). The outcome is what matters: you use our common
standard, and it's good for you, us, the providers and the consumers.
Oh, and, btw we also need to assure implementers that HL7 will not be
a capricious or undeserving steward of the work, so we don't try and
come up with some exclusivity with the license, whereby some
derivatives are ok, and some aren't. Whatever people want, that's
fine. We'll just be the best steward we can be.
So we started with that notional agreement. Which, I must say, seems
to me to apply to openEHR. I know that there's some in the community
who think that there should be some limits to commercial use for one
reason or another, or that if companies 'benefit' from the community,
they should be obliged to put back in (a Stallman kind of thing, but I
think that's self-limiting. we all have to earn a buck). It seems to
me that this kind of thinking doesn't apply to openEHR - the goals are
to help exchange health data, and unless there's some collective
fantasy that people are going to start providing healthcare for free,
it's always going to have a commercial element.
So we knew what we wanted. Initially, we considered the available CC
licenses, and others, and rejected them because they didn't have
anything in them about redefining conformance to the publication. As a
work around we adapted a license from the OMG, but that's not really
open, and it was generating problems for us because
- the fine print didn't quite say what we said in plain English
- because it wasn't a standard license, people needed to review it /
pay for lawyers to review it
- using a non-standard license meant that some purists claimed we
weren't really open
I wanted to fix that, but the process of getting lawyer time and
dealing with the organizational approval process just seemed like too
big a mountain to climb
So Paul Biondich from OpenMRS got in contact with me, and offered to
pay for lawyer time to resolve this (I really appreciated that). His
lawyer (Larry Rosen) and I went back and forth on the plain english
license making sure that he understood exactly what we wanted. For
instance, our conformance thing wasn't a play for total control of the
eco-system (unlike some other companies), just a play to retain
control over the specification. Once he was clear what we wanted, he
pointed us at CC-0 - it does what we want (btw, Larry would like us to
do more about patents - as would I - but that really is a mountain too
big to climb). When I raised the issue of conformance not being
covered by the license, he pointed out that this is a not a *copy*ing
issue, but a *control of meaning*, e.g. trademark issue.
So we agreed that we would (a) adopt CC-0 and (b) beef up the
trademark protection. HL7's own lawyer wasn't really comfortable with
allowing derivative works, but that was actually an issue with our
intent. We need to allow derivative works because there's too many
things that should be allowed that a reasonably described as
derivative works. So I proposed this to HL7, and Chuck Jaffe (HL7 CEO)
took on the herculean task of steering that change through the
organization (it should have been straight forward because we weren't
changing the intent, but these things never are straight forward). We
beefed up the procedural stuff around trademark protection further
during that process, but not much else changed; it was mainly an
educative process.
So that's the background. The key question is to agree what you want
to achieve; the exact license is a vehicle, not a goal.
My personal opinion is that openEHR should do what FHIR has done, and
for the same reasons: you should want everyone to use the work without
hesitation, but you don't want someone to try and grab control from
the community. So, I think openEHR should find a partner in the US to
hold the openEHR trademark - something that big corporates couldn't
ignore. IHTSDO, HL7, AMIA, something. And then adopt CC-0.
I really like where we are now because when the open source people
come my way, I can tell them that we're really really unencumbered in
a way that they haven't go the guts to do. They still insist on
attribution etc. So there!
Grahame
