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

[Richard Fontana]

On Sun, 6 Oct 2013 14:00:43 -0700
Howard Look <howard at tidepool.org> wrote:

> 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."

Those are good examples to consider. We also have to think about how
this license might be used by other individuals and organizations
with other software. 

I think this is a very interesting license, perhaps the most
interesting 'open-ish' license I've seen in years. The main issue I see
with it has to do with the breadth of the key 3(C) feature.

Despite what the OSD literally says or doesn't say, there is an
expectation in open source that there is some large zone of software
user privacy, obviously a different form of privacy from the one your
license is focused on. It is for this reason that people often say
(with some inaccuracy) that 'if you're only engaged in internal use,
you don't have to worry about the requirements of open source
licenses', or variations on that, often when arguing how open source
licenses have advantages over proprietary licenses. The key idea is
that open source licenses are supposed to be highly unburdensome --
more unburdensome than the same licenses may be in the distribution
context -- if use of the software is not 'public' or external in
nature. 

Regardless of what the OSI may have decided on any particular license
in the distant past, I do not believe a license that required
publication of source code for all acts of purely private or internal
modification would be legitimately regardable as 'Open Source', because
it would violate this traditional software user privacy principle. The
outer bound here, to me, is represented by AGPLv3 and perhaps some of
the past OSI-approved licenses that had similar conditions, where the
justification seemed to be that it is okay to treat network services
interaction as comparable to distribution.

Here, compliance with 3(C) will require publication of data subject
information for the data subject even for cases of internal use. It is
apparent that in some cases this will also include providing source code
for at least some portion of some software being used (which I suppose
could be software that is entirely unrelated to your software, which
might violate the spirit of OSD # 9, or violate it by implication).

One can argue there's a special policy justification here that is
absent in the case of some license that required publication of source
code for all internal use, but I'm not sure why. Copyleft licenses are
predicated on the idea that there is a strong policy justification for
members of the public getting access to source code, but, I am
contending, we have traditionally balanced that against the software
user privacy principle.

This is not a conclusion about the license, but an attempt to focus on
what I think the main issue is.

 - RF