Here's a link to the current project's source if anyone is interested: <a href="https://github.com/researchkit" rel="nofollow">https://github.com/researchkit</a><p>Love that Apple is going open-source, and hopefully they do this for more of their code (pssssttt...Swift)
While it's wonderful they did this, as a short rant:<p>I hate when companies just feel the urge to add a random sentence or two to an existing license, particularly in cases like these:<p>"3. Neither the name of the copyright holder(s) nor the names of any contributors may be used to endorse or promote products derived from this software without specific prior written permission. No license is granted to the trademarks of
the copyright holders even if such marks are included in this software."<p>The first sentence is BSD, they added the second sentence.
The problem with this is a few-fold.<p>Either this clause is needed <i>for the entire world</i> (since BSD is used for trademark'd software all the time), or it's <i>not needed at all</i>.<p>It turns out, in fact, arguments over trademark inclusion due to OSS licensing has been made before, and nobody has ever won on this before[1]
So other than some lawyer just "not being satisfied unless they added stuff to the license", all this does is make a gratuitously different license that<p>A. can't be merged with other licenses (since it requires you reproduce <i>this</i> condition text, and <i>this</i> condition text is not the same anymore as the other ones)<p>B. Isn't actually the BSD license, and was deliberately changed, so ends up worse in court since now the other side can reasonably argue that the same precedent should't apply.<p>C. Makes analyzing compatibility with other licenses more difficult and annoying.<p>[1] Since they are very clearly licenses about the software work, not trademarks, and you can't stop someone from saying "this uses apple's researchkit" regardless of what trademarks you have or what you write in this license, anyway.
I'm not an Apple fan but this is very professionally done, it reminds me of the work an Orthopedic Sureon had me do for him years ago when I see the layout: <a href="http://researchkit.github.io/docs/docs/Overview/GuideOverview.html" rel="nofollow">http://researchkit.github.io/docs/docs/Overview/GuideOvervie...</a><p>The flow is consistent, step 1, step 2, etc.<p>Something else that Apple makes I'm a fan of, CUPS Printing. It's also very professionally done. If we could only convince Apple to go Linux on everything!
It's interesting to see how code is structured when it comes from Apple (or vendors they're working closely with).<p>Surprising some of their best practices aren't followed, such as hard-coding English strings instead of using something like NSLocalizedString()<p>(e.g. <a href="https://github.com/ResearchKit/GlucoSuccess/blob/master/Diabetes/TasksAndSteps/EnterWeight/APHEnterWeightTaskViewController.m" rel="nofollow">https://github.com/ResearchKit/GlucoSuccess/blob/master/Diab...</a>)
I wonder if I can use this along with a raspberry Pi & Arduino to offer automated customized services to my patients.<p>E.g. build a system with RFID cards that uses sensors to automatically measure blood pressure, etc[1] and keep history.<p>ps. Too many interesting possibilities out there and too little time to pursue them!<p>[1] <a href="http://www.cooking-hacks.com/documentation/tutorials/ehealth-biometric-sensor-platform-arduino-raspberry-pi-medical" rel="nofollow">http://www.cooking-hacks.com/documentation/tutorials/ehealth...</a>
It's a start! There is big space for improvement in supporting the complexities of research studies, but this can definitely be a jumping-off and may well support broad consistencies in design and implementation.<p>There would still be a massive effort to implement most of the requirements of a research study. But, at least the iOS UI implementation and some on-ramps via ActiveSteps would be eased.