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

[Howard Look]

On Oct 5, 2013, at 8:37 PM, Richard Fontana wrote:
> 
> On Sat, 5 Oct 2013 11:58:36 -0700
> Howard Look <howard at tidepool.org> wrote:
> 
>> “Open” as applied to Health Data will have the meaning ascribed to
>> such term by the Open Definition promulgated at opendefinition.org,
>> version 1.1 and any later version; 
> 
> What if a future version of the Open Definition conflicts with the
> current version? (Should "and any" be "or any"?)

Great point, thanks. I think you are right and it should be "or any."

>> For avoidance of doubt, as applied to Health Data under this license,
>> “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, in both
>> human-readable and machine-accessible forms.
> 
> A comment on the end of this sentence: You say in your FAQ:
> 
>  Q: Is it good enough to provide access to a downloadable CSV or excel
>  file?
> 
>  No, that's not good enough. You need to provide a mechanism for
>  another application to automatically access the data, such as through
>  a published API. This is what we mean by "machine-accessible."
> 
> Perhaps you should define "machine-accessible" in the license as I am
> not sure it would be obvious that, say, a CSV file would not satisfy
> the requirement.

Yes, we struggled with this. We were trying to avoid including specific
technology. In today's terms, we want to say something like "just giving
access to downloading a CSV or PDF of the data is not good enough;
you need to provide RESTful API access to the data."

I would love suggestions anyone had for license language that achieve this but
that don't refer to specific machine-accessibility techniques.

> 
>> (C) Open Health Data.  You must ensure that the Health Data remains
>> Open to its Data Owner for a period of three years after the Health
>> Data is first generated.  
> 
> Am I correct that, under this license 3(C) is meant to be triggered even
> if the user is engaged in purely internal or private use of the
> software? (Perhaps this is not a usage you contemplate for the
> software you intend to release, but I think it is a key issue to be
> considered.)

Excellent question. I think that if a clinic or hospital adapted
our code for use with their patients, then we would expect that they would
make the data collected available to patients, even if it was a completely
private institution.

We also discussed the case of "purely internal" for example if a research
institution was doing a study using our platform. We decided that it
was important to us that even in this case that data be made available
to the patient if they so desired.

Please let us know if you are envisioning something else in the way
of "private use" pr "purely internal."

Thank again! We really appreciate your thoughtfulness. This will definitely
help us make sure we get this right.

Cheers,
Howard


> 
> - RF
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20131006/2bbc223b/attachment.html>