<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi everyone,</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">My apologies for the delay in following up on this thread. Thank you all for taking the time to review our request and for your wonderful and insightful feedback on the draft Tidepool License.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Since several folks touched on similar topics, both on the thread and in private emails, I will attempt to consolidate and summarize here. My apologies in advance if I've missed anything substantive.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><div style="font-family: Arial; ">== Concerns over what data needs to be made open ==</div><div><font face="Arial"><br></font></div><div><font face="Arial">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.</font></div><div><font face="Arial"><br></font></div><div style="font-family: Arial; ">This has been the most challenging part of crafting this new license. In short, should we require _all_ data to be made available (including interim and diagnostic data), or just the "end result" data that is typically displayed or made available to the doctor or patient? As Nigel Tzeng points out, interim data might include a whole lot of interim data (e.g. k-space data from an MRI) that isn't ever stored or made available. </div><div style="font-family: Arial; "><br></div><div style="font-family: Arial; ">More examples: In the case of diabetes devices, Continuous Glucose Monitors typically measure Interstitial Fluid Glucose value (typ. called ISIG), which is then converted to a blood glucose. An engaged patient, or a developer/researcher who wants to make a better closed loop algorithm, will want to know both ISIG and BG. In the case of an Implanted Cardiac Defibrillator, an engaged patient will want to know lead impedance, diagnostic info that is collected and can be an early indicator of device malfunction.</div><div style="font-family: Arial; "><br></div><div style="font-family: Arial; ">The challenge is in not creating a field of endeavor restriction. We kind of would like to say "make everything available" but it's not always practical. But there are medical devices and services today where data is collected and stored, and that data _is_ made available to the device company or to doctors, but _not_ to the patient.</div><div style="font-family: Arial; "><br></div><div style="font-family: Arial; ">So perhaps a pragmatic solution is to say: If you gather health data that is stored and intended to be accessed by anyone (e.g. doctor or device maker) then it must be made available to the patient. In the mind of OSI members, does this create a field of endeavor restriction? Or is it actually an "anti-restriction" and therefore in the spirit of OSI's tenets?</div><div style="font-family: Arial; "><br></div></div><div apple-content-edited="true">== How data is accessed ===</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">We will remove the language from our FAQ saying anything like "CSV download isn't good enough; must use RESTful APIs." The real issue, as many pointed out, is making sure the right data is accessible, and accessible in an automated fashion without hinderance (e.g. not thwarting people or machines from accessing the CSV data). </div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Josh Berkus, thanks for proposing this language. We'll have our lawyers take a look.</div><div apple-content-edited="true">"The User shall have the right and ability to access their complete, up-to-date, documented, and machine-readable structured data, on demand, as many times as the User requires. No additional requirements, whether fee, registration, or other burdens, shall be placed on the User for access of the User's data except as absolutely necessary to verify their identity."</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">== Should this license apply to all personal data, not just health data? ==</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">While we agree with the premise and suggestion, our concern is that attempting to make this work for all personal data will be too broad and hard to define effectively. Since Tidepool's mission is centered around type 1 diabetes care, we are deeply immersed in health care issues and therefore more comfortable being the stewards of a license that pertains specifically to health data. We would be in total support of another steward drafting a license that applied to all personal data, and would support using our license language as a starting point if they so desired.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">== Accessibility of data for private use, e.g. in research studies ==</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Several folks noted that the proposed access to data language might be challenging for researchers who might not want to make data available for patient access during the course of a study, or before the results have been analyzed or published.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Indeed, this is something we considered, and we could not come up with language that would not be counter to "no restrictions on field of endeavor" OSI requirement.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">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.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">We believe that this also applies to "private" use. E.g. if an individual clinic adapted code under the Tidepool license to internal, private use, and they collected health data, we would expect them to make that data available in machine-accessible form. If they don't desire to do that, then they should not choose to use or adapt code under the Tidepool license.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">== Concern over incompatibility with health data privacy laws, e.g. HIPAA ==</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">We did consider this, and since we are limiting required access to the Data Owner, we think it is compliant with HIPAA and furthermore is even supportive of the "portability" part of HIPAA.<br><br>This point is one of the reasons why we couldn't just use the Open Definition as is, since it refers to access to "everyone/anyone." In the case of this License, the intent is that access is just open to the Data Owner (e.g. the person whose body was the source of the data) or their designate.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><div style="font-family: Arial; "><div apple-content-edited="true" style="font-family: Helvetica; ">== Concerns over patent language by universities/research institutes ==</div><div apple-content-edited="true" style="font-family: Helvetica; "><br></div><div apple-content-edited="true" style="font-family: Helvetica; ">We mentioned that UCSF had expressed concerns about our patent language (which is adapted from Apache2). Nigel suggested we look at ECLv2 which addresses this specifically:</div><div apple-content-edited="true" style="font-family: Helvetica; "><div style="font-family: Arial; "><a href="http://opensource.org/licenses/ECL-2.0">http://opensource.org/licenses/ECL-2.0</a></div><div style="font-family: Arial; "><br></div><div style="font-family: Arial; ">This does look compelling. I will have UCSF and our lawyers review this. Thanks for the lead, Nigel!</div><div style="font-family: Arial; "><br></div></div></div><div style="font-family: Arial; ">== Concerns over FAQ language around UI designs ==</div><div style="font-family: Arial; "><br></div><div><font face="Arial">"This license applies to anyone who wishes to incorporate Tidepool<br>software or UI designs in any way, for example in a device, in a mobile<br>app, or in a web-based service or a PC/Mac/Linux desktop application."</font></div><div><font face="Arial"><br></font></div><div><font face="Arial">Indeed, good catch. The UI designs are protected by copyright, but not by this license. We will edit this language.<br><br></font></div></div><div apple-content-edited="true">== Concern about dual-license approach and GPL ==</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">(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.)</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">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. 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.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">We will consider dropping the dual-license approach and just releasing our code under the Tidepool license. As stated in the blog post, while we support the tenets of copyleft and GPL, the practical reality seems to be that most enterprises, and especially the ones would most likely benefit from building devices and services using Tidepool-licensed code, would simply be scared away by GPL.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">==</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Thanks again to everyone who took the time to read our proposal and provide feedback. We look forward to your continued insights.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Regards,</div><div apple-content-edited="true">Howard Look</div><div apple-content-edited="true">President/CEO, Tidepool</div><div apple-content-edited="true"><a href="mailto:howard@tidepool.org">howard@tidepool.org</a></div><div><br></div><div apple-content-edited="true">
</div>
<br><div><div>On Oct 5, 2013, at 11:58 AM, Howard Look wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hello!<br><br>== Overview ==<br><br>My name is Howard Look. I am President/CEO of Tidepool Project. We are a non-profit, (soon to be) open source project creating an open platform and applications to help reduce the burden on people with Type 1 Diabetes. We are proposing that we a new create a new license, the Tidepool Open Access to Health Data Software License.<br><br>Our company and efforts are described here:<br><a href="http://tidepool.org">http://tidepool.org</a><br><br>Our rationale and proposed license strategy is detailed here: <br>http://tidepool.org/blog/2013/9/17/wheres-the-code-or-a-funny-thing-happened-while-on-the-way-to-an-open-source-license<br><br>The draft license is here (and in plain text below):<br>http://tidepool.org/license<br><br>FAQ is here:<br>http://tidepool.org/tidepool-license-faq<br><br>== Rationale ==<br><br>We want to require applications, devices and services to keep health data open and accessible to patients, their designated caregivers.<br><br>We could not find a source license that included an open data provision. Various open data licenses were close (see http://opendefinition.org/licenses/), but they covered the data and not the software or devices creating the data. They also require open access to everyone, which is not appropriate for private health data where the patient should choose who has access to their data.<br><br>We intend for the Tidepool license to be reusable by others. Our initial intent is to license the code created by the Tidepool project, which makes it easier to gather data from various diabetes devices, and to analyze that data in intuitive and actionable ways.<br><br>== Distinguish ==<br><br>The Tidepool license is permissive as to source code, and "copyleft" as to the open data requirement. The license is most similar to the Apache v2 license, though with the addition of the open data provision.<br><br>== Legal Review ==<br><br>The license was drafted by Heather Meeker of Greenberg Traurig, who also participated in the creation of the Mozilla licenses.<br><br>We have asked for legal review from institutions that we hope to collaborate with, so far UCSF and Stanford, as well as from medical device companies such as Medtronic and Dexcom.<br><br>UCSF has concerns about the patent provision and it's broad reach across the UC system. We are awaiting further clarification about whether this is a unique to the Tidepool license, or whether they have similar concerns about they Apache license, for example.<br><br>We have not received any other legal review.<br><br>== Other Feedback ==<br><br>So far, the feedback on our plan falls into these rough buckets:<br>0 - Only use GPLv3. Truly free and open software is the only way to go for medical devices and therapy software.<br>1 - Steer clear of GPL at all costs. It's a third rail and will cause enterprises to not look at your code. Not worth it.<br>2 - The dual-license approach is way more confusing than it's worth.<br>3 - Doing a new permissive license is more confusing than it's worth. Just release it under MIT/BSD/Apache and let it speak for itself.<br>4 - We love that you are doing a new permissive license and totally agree that patients must own and have access to their own health data.<br><br>== Proliferation category ==<br><br>We hope that the Tidepool license is reusable, and put it in the category of "Special purpose licenses." We hope that it is reusable by other projects delivering hardware and software medical technology. We discussed this, for example, with members of the Implanted Cardiac Defibrillator community, who have similar desires as the diabetes community for open patient access to data.<br><br>Please let me know if you have any further questions. Thanks in advance for your feedback and consideration.<br><br>Regards,<br>Howard<br><br><br>[DRAFT - This draft is open for public review and comment. Please email your comments to legal@tidepool.org or comment on the associated blog post at http://tidepool.org/blog/2013/9/17/wheres-the-code... published September 17, 2013.]<br><br>TIDEPOOL OPEN ACCESS TO HEALTH DATA SOFTWARE LICENSE V1<br><br>This license governs the use of the software to which this license notice is applied (“Software”). You are not required to accept these license terms; however, nothing else grants you permission to modify or distribute the Software or its derivative works. The purpose of this license is to ensure that any use of this Software is conditioned upon making Health Data collected or processed by the Software Open to the Data Owner or any party authorized by the Data Owner, and this license should be interpreted in service of that purpose. <br><br>1. Definitions. As used in this license, the following terms have the following meanings.<br><br>A “Contribution” is the Software, or any modification or addition to the Software made available under this license. <br><br>A “Contributor” is any person or entity that makes available any Contribution under this license. <br><br>“Data Owner” means the natural person to whom the Health Data applies.<br><br>“Distribute” means to distribute, transfer a copy of, or otherwise make available (including via network access).<br><br>“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.<br><br>“Licensed Claims” are all claims in issued patents or pending patent applications owned or controlled by any Contributor or any of its Subsidiaries, now or in the future, having claims that, absent the license granted in Section 2(B), would be infringed by the making, having made, use, sale or other exploitation of that Contributor’s Contribution, or by the combination of the Contribution with the remainder of the Software (where such infringement would not arise based on the Software standing alone without the Contribution).<br><br>“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; provided, however, that no condition of attribution will be applied to use of Health Data and the Health Data need not be made available or accessible to any party other than the Data Owner or parties authorized by the Data Owner. 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. When you provide Health Data in machine-accessible forms, you must also provide data format descriptors suitable for other programs to read the Health Data.<br><br>Any reference to the “Software” includes the Software, in whole or in part, in any medium or any format (such as binary or source code).<br><br>A “Subsidiary” is an entity that is controlled, directly or indirectly, by a Contributor.<br><br>In this license, “you” refers to any recipient of the Software.<br><br>2. Grant of Rights<br><br>(A) Copyright Grant. Subject to the license conditions and limitations in section 3, each Contributor hereby grants you a non-exclusive, perpetual, irrevocable, worldwide, fully paid-up, royalty-free copyright license to reproduce, prepare derivative works of, and Distribute its Contribution, in whole or in part, or any derivative works thereof that you may create under the foregoing license grant.<br><br>(B) Patent Grant. Subject to the license conditions and limitations in section 3, each Contributor hereby grants you a non-exclusive, worldwide, royalty-free license under the Licensed Claims to make, have made, use, sell, offer for sale, import, and otherwise dispose of its Contribution, and to practice any method embodied therein.<br><br>(C) No Sublicense. This license does not grant you the right to sublicense the rights granted to you in this license. Each time you Distribute the Software, the recipient automatically receives a license directly from the Contributors, subject to the terms of this License.<br><br>3. Conditions<br><br>(A) License Notice. If you Distribute the Software, whether in source code or binary format, you must provide the recipient with a copy of this license, which will govern the Software. Such notice may be delivered via any reasonable means that gives the recipient effective notice.<br><br>(B) Defensive Termination. If you bring a claim against any Contributor alleging that the Software directly or indirectly infringes any patent claim, the patent license granted to you under Section 2(B) will automatically terminate.<br><br>(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. <br><br>(D) Notices. If you Distribute the Software, you must retain all copyright notices that are present in the Software.<br><br>(E) Source Code Distribution. If you Distribute the Software or any derivative work thereof in source code form, you may do so only under this license by including a complete copy of this license with your distribution. For clarity, any source code file that does not contain any portion of the Software (other than interface definitions as necessary to interoperate with the Software) is not considered a derivative work of the Software. You may Distribute the Software in binary form under terms of your choice, so long as any license to redistribute the Software includes all of the conditions in this Section 3. For clarity, this license does not require you to deliver any source code to any recipient, except to the extent it may be necessary to comply with the conditions regarding Open Health Data in Section 3(C).<br><br>(F) Disclaimer. The Software is provided "as-is." All Contributors hereby disclaim, to the maximum extent possible under law, any and all warranties, guarantees or conditions, express or implied.<br><br><br></div></blockquote></div><br></body></html>