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

[Howard Look]

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/20131024/4c0892eb/attachment.html>