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

Sun Oct 6 03:36:35 UTC 2013

On Sat, Oct 5, 2013 at 1:05 PM, Howard Look <howard at tidepool.org> wrote:
> We did indeed consider GPL but heard loud and clear from enough folks that many (if not most) for-profit institutions simply will not consider GPL code (especially GPLv3 code, which we really would need for devices), which would really limit our mission of helping as many people as possible with diabetes. Hence our desire to also provide a permissive license to maximize the chance of our code being adopted.

I see. I wish this GPL[v3] allergy did not exist, but I understand
your reason for offering a completely separate alternative license
now.

> We also discussed the "field of endeavor" issue, and indeed that's a concern. In this case, we hope that our restriction is really an anti-restriction (you must make the data _available_ to the patient), which I believe is the intent of the open software + open data overlap, as you point out.

I doubt it, but we'll see what folks on license-review say.

Imagining a case in the other direction, if there were a wants-to-be
Open Definition license that required that only open source software
be used to process the data, I very highly doubt it would be approved
as OD compliant, due to field of endeavor restriction (the Open
Definition is basically a copy of the Open Source Definition, tweaked
for non-software works).

But it in a sense it doesn't matter. Your software will be open
source, as anyone can take the GPLv3 option if they want. Lots of open
source software is also available under other, less than open source,
often plain old proprietary terms.

> I'm afraid I'm not quite following:
>> strong effectiveness as an allow-sharing/collaboration mechanism.
>> Which means non-license regulatory mechanisms need to be prioritize
>
> Which mechanisms are you referring to in both cases?

In the first, granting permissions around whatever restrictions are
presenting in the default regulatory environment (mainly copyright and
patent). This is what public licenses do first, whether classed as
permissive or copyleft.

The second, I mean any mechanism that does not require a rightsholder
to grant permission or to enforce pro-sharing stipulations conditioned
upon granted permissions. These could include, on the side of
permission, many of the items in the usual "copyright reform" list as
well as increased customer and funder demand for such permission. On
the side of pro-sharing stipulations, regulation which is based on a
achieving some policy end directly (eg mandate patients have a right
to data about them, period; or that software running in safety
critical systems be auditable by the public, period), as well as
increased customer and funder demand for data, source, transparency,
etc.

I'd said that public licenses have been effective at granting
permissions, but really they are very limited in being opt-in, and
non-license mechanisms are badly needed there too. But the need is
even greater on the pro-sharing stipulation side, as these are hard to
get "right" (eg it isn't always obvious which are "anti-restrictions",
and which restrict who can use a work, for what; also it is hard to
align these stipulations and not also cripple the commons through
incompatible stipulations), rely on another level of opt-in for
enforcement, eg a developer having the
connections/knowledge/means/will, and sadly are not on the usual
"copyright reform" agenda.

This is all pretty far off topic; I was only musing to the Open
Definition community why I found your license interesting, and got
carried away. :) But if anyone wants more bad writing on these points,
see http://gondwanaland.com/mlog/2012/02/25/permissions/
http://gondwanaland.com/mlog/2012/01/31/copyleft-regulates/ and the like.

Mike