[License-review] Request for approval by license steward: Tidepool Open Access to Health Data Software License

Fri Oct 25 15:15:00 UTC 2013

Howard,

I'm still not sure why you are proposing a health data license that, at
best, will affect only a small number of devices and data, rather than a
statute that will guarantee the right of all patients to their own health
data. Laws can be more effective than licenses.

/Larry

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm ( <http://www.rosenlaw.com/>
www.rosenlaw.com)

3001 King Ranch Rd., Ukiah, CA 95482

Office: 707-485-1242

Linkedin profile:  <http://linkd.in/XXpHyu> http://linkd.in/XXpHyu 

From: Howard Look [mailto:howard at tidepool.org] 
Sent: Thursday, October 24, 2013 11:45 AM
To: Richard Fontana
Cc: License submissions for OSI review
Subject: Re: [License-review] Request for approval by license steward:
Tidepool Open Access to Health Data Software License

On Oct 24, 2013, at 10:42 AM, Richard Fontana wrote:

On Sun, 20 Oct 2013 21:01:24 -0700
Howard Look <howard at tidepool.org> wrote:

== Concerns over what data needs to be made open ==

Draft license text: "Health Data" means data pertaining to the

physiological functions of a natural person, including any

information or data specific to understanding the operation, safety

or efficacy of a device or service that accompanies, is assistive in

understanding, or generates such data.

Howard, can you clarify whether 'Health Data' can encompass software
itself (i.e., might not there be software that is 'specific for
understanding the operation safety or efficacy of a device or service
that accompanies, is assistive in understanding, or generates' Health
Data in a more intuitive sense)?

Hi Richard, our intent is that "health data" would not encompass software,
though it is indeed possible that there are cases where the raw data alone
would not be sufficient to make interpretations.

Our intent is, at a minimum, to make the data available. Making the software
to interpret the data also available is a big bonus, but not the intent nor
a requirement of the license.

A caveat to the above: It is clearly important that the data at least be
readable, which is why we included this: "Open" means that in the event you
apply any encryption or obfuscation to the Health Data using the Software,
you must provide the Data Owner with any encryption keys or other suitable
means, free of charge, to access such Health Data, in a manner sufficient to
allow a Data Owner with ordinary skill and knowledge to extract and store
the Health Data in a non-proprietary format...

[...]  
For many research studies that use our code, we think that making the

data open to patients _is_ practical, and so this license could

apply. In cases where it's not practical (because it's interim,

unpublished data, for example) a possible solution, at least for

Tidepool, will be to make it clear to researchers that while we

encourage them to make their data open to their study patients, they

can approach us (Tidepool) about licensing our code under different

license terms.

If there is an issue as to this point wrt whether the license is 'Open
Source' (I'm not saying there is), I consider the argument that 'if
it's too burdensome, they can always ask for a different license'
unsatisfactory. 
[...]

Yes, I see your point. I think there may actually be two issues here,
"burden" and "appropriateness." In the case of a research, it may be about
both burden and appropriateness, but my intent was to address
appropriateness above, i.e. it may not be appropriate to release the data to
patients while the study is going on, for example because the results need
to be compiled and studied and published.

In the the case of burden, i.e. "I don't want to do the work needed to
create patient- and machine-accessible APIs," you are correct, our intent
would not be to offer an alternate license for that reason.

== Concern about dual-license approach and GPL ==

(This point is a bit orthogonal to seeking OSI approval for the

Tidepool license, but it is addressed in the blog post that we

referenced in our request for approval, we got several comments on it

private messages.)

Several folks have encouraged us to _not_ use a dual license approach

as it creates downstream confusion about how to apply the license and

has fallen out of favor.

Possibly off-topic but I find the 'fallen out of favor' odd. It seems
that there may be a confusion between 'proprietary/open source dual
licensing' (which I agree has fallen out of favor) and 'disjunctive
open source dual-licensing) (which is about as common as it ever has
been). 

Yes, thank you for clarifying. I based that statement on the feedback we'd
received, but didn't look up the data on dual-license use nor was I precise
about the type of dual license (disjunctive vs. proprietary).

I'll try to be more precise: There are three issues that have come up, all
multiple times:

1) Concern about any reference to GPL 

2) Confusion about dual-licensing (how it is interpreted, how to indicate
it)

3) Concern about us offering a new license at all

As I think is often the case with concerns or confusion, there is an
education effort that could mitigate them. However not everyone is willing
to spend the time or energy to be educated, and it also takes time and
energy on our part, which is not core to our mission of helping people with
type 1 diabetes, so as the saying goes, we need to pick our battles. In this
case, we are choosing to pick #3, but not #1 and #2. (And to be clear, we
are also getting lots of feedback to not pick #3.)

On #1, we have gotten feedback directly from enterprises that we would hope
to work with, and also from lawyers who support them, as well as other
entities that deliver software to them, that they will simply not even look
at code, or even pay a lawyer to look at the license if it has the word
"GPL" in it, even in the case of a disjunctive dual license.

Here is a sampling of the email feedback (these were all sent in private, so
removing attribution):

"you definitely should not use GPL, or even dual license under that - it's a
policy issue that will prevent you getting in the door (whether that's valid
or not)"

"we won't include GPL or proprietary licenses in our work, so we wouldn't
use your stuff. We wouldn't even pay a lawyer to read the license-life's too
short. "

"Why even touch the third rail of GPL?"

"The key thing about open-source licensing is to keep it simple and,
ideally, standard. Dual licensing is no longer in vogue, and for good
reason: it's incredibly difficult to explain how dual-licensing works in
practice, and so people tend to stay away. Niche/Custom licenses (e.g.
Tidepool Open Access?) are even worse: how do you know if that's compatible
with other code published under, say, an Apache license? Do you have to get
a lawyer to find out?"

"I'm not sure I'd like to be contained to have all of my app be released
under GPL."

Again, it makes us sad, too, because we do believe that completely open code
will make for safer health devices systems over time. We hope that some
entities will choose to publish all of their code, even though they are not
required to under the Tidepool license. We certainly intend to.

Some of these same folks, as well as other

folks, have encouraged us to not refer to GPL or copyleft at all in

our license strategy, since that will scare away most enterprises. As

indicated in our blog post, our intent is to encourage the broadest

possible adoption, while maintaining an open data requirement.

I think I asked this before, and I apologize if you answered it, but I
am curious why you think your license is inherently less scary than the
GPL.

Let me ask you this, though it is seemingly off topic: What will you do
if you find that enterprises turn out to be just as fearful of your
license as you believe they are of the GPL?

You are correct, that some (but we hope not all) enterprises will be fearful
of our license. We have been actively seeking feedback from device and
software manufacturers in our space (diabetes technology), as well as
research institutions that might use our code, and continue to seek
feedback.

So far, enterprises seem to fall into two camps:

1) Those who inherently agree that the patient owns their own data, and that
they should always have access to it, and should be able to elect to do
whatever they want with the data.

2) Those who do not agree with this entirely, for example they may believe
that the data they collect has monetary value, or could be used to deduce
their intellectual property, or that patients should not be able to give it
to their competitors, or that patients may not have the skills to interpret
the data.

We presume that the latter type of enterprise (2) will choose to not adopt
software under the terms of our proposed license, and believe that the
former type (1) will, and that over time they will be able to grow their
business and market share as patients, doctors and researchers see the value
in the open data approach.

Thanks again for the great questions and feedback! Please keep it coming.

Regards,

Howard

- RF

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20131025/9b87e33a/attachment.html>