<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Oct 24, 2013, at 10:42 AM, Richard Fontana wrote:</div></div></span></div></span></span></div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Sun, 20 Oct 2013 21:01:24 -0700<br>Howard Look <<a href="mailto:howard@tidepool.org">howard@tidepool.org</a>> wrote:<br><br><blockquote type="cite">== Concerns over what data needs to be made open ==<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Draft license text: “Health Data” means data pertaining to the<br></blockquote><blockquote type="cite">physiological functions of a natural person, including any<br></blockquote><blockquote type="cite">information or data specific to understanding the operation, safety<br></blockquote><blockquote type="cite">or efficacy of a device or service that accompanies, is assistive in<br></blockquote><blockquote type="cite">understanding, or generates such data.<br></blockquote><br>Howard, can you clarify whether 'Health Data' can encompass software<br>itself (i.e., might not there be software that is 'specific for<br>understanding the operation safety or efficacy of a device or service<br>that accompanies, is assistive in understanding, or generates' Health<br>Data in a more intuitive sense)?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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...</div><br><blockquote type="cite"><div>[...] <br>For many research studies that use our code, we think that making the<br><blockquote type="cite">data open to patients _is_ practical, and so this license could<br></blockquote><blockquote type="cite">apply. In cases where it's not practical (because it's interim,<br></blockquote><blockquote type="cite">unpublished data, for example) a possible solution, at least for<br></blockquote><blockquote type="cite">Tidepool, will be to make it clear to researchers that while we<br></blockquote><blockquote type="cite">encourage them to make their data open to their study patients, they<br></blockquote><blockquote type="cite">can approach us (Tidepool) about licensing our code under different<br></blockquote><blockquote type="cite">license terms.<br></blockquote><br>If there is an issue as to this point wrt whether the license is 'Open<br>Source' (I'm not saying there is), I consider the argument that 'if<br>it's too burdensome, they can always ask for a different license'<br>unsatisfactory. <br>[...]<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div><br><blockquote type="cite">== Concern about dual-license approach and GPL ==<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(This point is a bit orthogonal to seeking OSI approval for the<br></blockquote><blockquote type="cite">Tidepool license, but it is addressed in the blog post that we<br></blockquote><blockquote type="cite">referenced in our request for approval, we got several comments on it<br></blockquote><blockquote type="cite">private messages.)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Several folks have encouraged us to _not_ use a dual license approach<br></blockquote><blockquote type="cite">as it creates downstream confusion about how to apply the license and<br></blockquote><blockquote type="cite">has fallen out of favor.<br></blockquote><br>Possibly off-topic but I find the 'fallen out of favor' odd. It seems<br>that there may be a confusion between 'proprietary/open source dual<br>licensing' (which I agree has fallen out of favor) and 'disjunctive<br>open source dual-licensing) (which is about as common as it ever has<br>been). <br></div></blockquote><div><br></div><div>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).</div><div><br></div><div>I'll try to be more precise: There are three issues that have come up, all multiple times:</div><div><br></div><div>1) Concern about any reference to GPL </div><div>2) Confusion about dual-licensing (how it is interpreted, how to indicate it)</div><div>3) Concern about us offering a new license at all</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>Here is a sampling of the email feedback (these were all sent in private, so removing attribution):</div><div><br></div><div>"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)"<br></div><div><br></div><div>"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. "</div><div><br></div><div>"Why even touch the third rail of GPL?"</div><div><br></div><div>"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?"</div><div><br></div><div>"I'm not sure I'd like to be contained to have all of my app be released under GPL."</div><div><br></div><div><div>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.</div></div><br><blockquote type="cite"><div><br><blockquote type="cite">Some of these same folks, as well as other<br></blockquote><blockquote type="cite">folks, have encouraged us to not refer to GPL or copyleft at all in<br></blockquote><blockquote type="cite">our license strategy, since that will scare away most enterprises. As<br></blockquote><blockquote type="cite">indicated in our blog post, our intent is to encourage the broadest<br></blockquote><blockquote type="cite">possible adoption, while maintaining an open data requirement.<br></blockquote><br>I think I asked this before, and I apologize if you answered it, but I<br>am curious why you think your license is inherently less scary than the<br>GPL.<br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Let me ask you this, though it is seemingly off topic: What will you do<br>if you find that enterprises turn out to be just as fearful of your<br>license as you believe they are of the GPL?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>So far, enterprises seem to fall into two camps:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks again for the great questions and feedback! Please keep it coming.</div><div><br></div><div>Regards,</div><div>Howard</div><br><blockquote type="cite"><div><br>- RF<br></div></blockquote></div><br></body></html>