zhhealthcare wrote on Friday, January 17, 2014:
There seems to be some apprehension about the licensing under which we intend to contribute code. We intend to contribute the care coordination and the lab interface modules under an open source licence. There need not be any concern about that.
Shameem C Hameed
ZH Healthcare
2010 Corporate Ridge, Suite 700
McLean VA 22102
ph: +1-703-340-8065 Ext: 6666
Direct: 571-766-8074
Fax: +1-703-890-8702
zhhealthcare wrote on Friday, January 17, 2014:
Hi,
We will make the necessary changes to include the logging mechanism as suggested and will commit it soon.
Thanks and Regards,
ZH Healthcare
kchapple wrote on Friday, January 17, 2014:
It looks like composer is already used because there is a composer.json and someone copied the composer.phar archive into the modules/zend_modules directory. It’s not clear if this was done intentionally by ZH, or cruft left over from their development environment.
The module installer itself also depends on ZF2, which makes the framework required if you want to use any modules, and requires all modules comply with ZF2.
Seems to me you’d want to use composer to “make” the release distribution packages, and manage dependencies on Zend using composer (1 file) rather than including Zend into OpenEMR (14MB of files, most of which aren’t needed.)
Developers should be able to use composer, and they do all the time.
End users downloading a “pre-built” package could download a premade release that includes the Zend Framework.
For any end user, ZF comes with a certain amount of installation headache (as you mentioned in one of your first posts) which includes enabling mod_rewrite.
Ken
mdsupport wrote on Friday, January 17, 2014:
zf2 should be treated like php+ - part of *AMP platform. Also consider that zf2 releases minor updates/fixes every 1-3 months. It would be tragic to tie zf2 updates to openemr updates.
Also ZH effort at this stage appears to be more to enable common zf2 based services/functions rather than managing module installation (and by extension uninstall?).
mdsupport wrote on Saturday, January 18, 2014:
If the long term goal is to make OpenEMR truly modular based on zend framework and extensible by multiple vendors, please review the Recommended Project Structure for Zend Framework MVC Applications.
As the Zend guideline states, one can always use custom profiles and bootstraps to make any structure work. But that will be constant fighting with framework defaults.
zhhealthcare wrote on Tuesday, January 21, 2014:
Hi,
We have made use of the logging mechanism available in OpenEMR as suggested and committed the changes. Once the documentation for the logging is available we are planning to make the necessary changes to the logging functionality to make it compatible with zend framework.
The github path for the commit is:
Thanks and Regards,
ZH Healthcare
mdsupport wrote on Wednesday, January 22, 2014:
If part of MU2 functionality is going to depend on zf2 based code, is there any document describing which criteria will be using zf2?
bradymiller wrote on Friday, January 24, 2014:
Hi,
My understanding is that basically all of the MU2 item currently being worked on (listed as owner) by ZH will be based on zf2:
http://www.open-emr.org/wiki/index.php/OpenEMR_Certification_Stage_II_Meaningful_Use#Certification_Criteria
Also shown on the completion barometer as the “Third Party Pending” items:
http://www.open-emr.org/wiki/index.php/OpenEMR_Certification_Stage_II_Meaningful_Use#Completion_Barometer
-brady
OpenEMR
bradymiller wrote on Friday, January 24, 2014:
Hi,
Regarding licensing issues, can folks weigh in if it will be ok to bring code with “New BSD License” and “GNU Affero General Public License”(version 3 or above) into the OpenEMR codebase.
-brady
OpenEMR
mdsupport wrote on Friday, January 24, 2014:
Just like PHP or Apache is not part of OpemEMR codebase, zf2 should not be either. If any user/owner misses the legalese, preferred/default directory structure of zf2 makes it explicit with the ‘vendor’ directory. That is why composer based distribution will be clean and keep anyone from taking shortcut by modifying someone else’s code.
When an installation downloads packages directly, they accept related terms and conditions.
bradymiller wrote on Friday, January 24, 2014:
Hi,
Reviewed your code here:
Looking forward to next revision.
-brady
OpenEMR
bradymiller wrote on Saturday, January 25, 2014:
Hi,
If this is in reply to my question on licensing above, note there is code (some Zend Framework glue and ZH’s code) that will definitely be in the openemr codebase (whether it is brought in before packaging a distribution or in the openemr repo). So the question stands:
Will it be ok to bring code with “New BSD License” and “GNU Affero General Public License”(version 3 or above) into the current OpenEMR codebase?
This is not a technical or philosophical issue, but a straightforward licensing question. It will likely require some background research and was hoping could get others to spend time doing this, since I’ve already spent hours on the code review process itself for this.
thanks,
-brady
OpenEMR
mdsupport wrote on Saturday, January 25, 2014:
May be it is lack of understanding on our part regarding purpose of ‘Zend Module Installer’. zftool installation if done by user, will bring in zf2. Once installed, the tool can create the basic structures for developers and ideally, composer does the install of new modules for users. Neither of these scenarios should raise licensing issues since new modules code is property of the creator (e.g. ZH) and zf2 developer would not need to modify vendor’s files (in vendor directory). Object world of zf2 should have no need for any modifications to the base classes provided by zf2. So again no licensing issues.
Guess Brady needs to use his powers of persuasion to get application architects to get actively involved since badly configured framework is worse than no framework at all as it will make everyone jump through meaningless hoops without getting any benefit out of the ‘framework’.
bradymiller wrote on Saturday, January 25, 2014:
Hi MD Support,
I have placed a code review for the most recent revision of ZH’s code. Please feel free to review the code and/or provide a actual working alternative mechanism. Note that the MU2 work done by ZH will be in Zend and will be using those licenses(read their code to get an idea of where it is used and note it’s not just in the zl2 library) and will at least be distributed in the turn-key xampp/openemr package, so it is my opinion that the question will need to be addressed at some point.
My question is simple:
Will it be ok to bring code with “New BSD License” and “GNU Affero General Public License”(version 3 or above) into the current OpenEMR codebase?
I am requesting thoughts from the community; perhaps there is somebody out there besides yourself whom has some thoughts on the matter and I see no reason why the question should be hindered.
thanks,
-brady
OpenEMR
tmccormi wrote on Saturday, January 25, 2014:
Brady,
No one in the community (to my knowledge) is a FOSS license expert. The OEMR will endeavor to get a real, expert opinion for us. I have reached out to Fred Trotter so far, as he is the the closest to an expert that I know personally.
If the ZEND framework is not acceptable, either legally or technically then we must find alternative contributions for the items ZH intends to us Zend for.
We can not risk delaying the completion of certification past June 1 with out, at the very least, betraying the trust of the primary financial contributors to that effort and at the worst losing our hard won footing in the EHR communities of the USA.
–Tony
OEMR President
bradymiller wrote on Saturday, January 25, 2014:
Hi Tony,
An expert is good, but the community has done well in the past sorting through licensing issues. Just requires some internet research (guessing an hour or so). My guess is that were fine; or at worst ZH may need to rethink their GNU Affero license choice. But will be important to clarify this.
This issue is not delaying anything; code has been reviewed and ZH is planning to release the module pertaining to ccda/Care Coordination anytime now for review. At this point, the only group working on MU2 items actively is ZH (there is also a volunteer developer working on the demographics MU2 item). So, if vendors/developers think MU2 is important, then I suggest they start working on it; there are lots of open items without owners:
http://www.open-emr.org/wiki/index.php/OpenEMR_Certification_Stage_II_Meaningful_Use#Certification_Criteria
-brady
OpenEMR
tmccormi wrote on Saturday, January 25, 2014:
I do not mean to say the community opinion is of no use, but to explain why no one has answered the question…
It is odd (and heartening) that ZH would choose Affero as it closes the cloud hosted apps loophole which allows vendor to keep GPL based code private. I met the guy that wrote that a few years ago at OSCON.
There are several vendors (and users) that are working on parts of the MU that have not come out of the wood works yet, I’m working on that. These same people are also contributing cash so we can pay others to get the certification and to do development.
I am glad ZH is working on things, I am concerned that the ZEND thing may be a show stopper, is all. I am not against ZEND, I’m the one that encouraged Shameem’s team to look at it to begin with.
Most people don’t seem to be be against it either, just concerned about the deployment model.
I don’t need to be pointed the project page, I look at it every day trying to find ways to get some more of it done.
–Tony
bradymiller wrote on Saturday, January 25, 2014:
Hi,
Sorry Tony. I know you are well aware of the MU2 project; link was directed towards everybody; I shouldn’t of addressed the post to only you.
I am ok with getting no answers on the licensing question; very common to get no replies on these type of posts, although it has only been several hours. I just didn’t want the question to get squashed because of potential philosophical/technical issues.
We are all in this together 
Would be nice to place the other stuff that you know is going on in the MU2 project page.
-brady
mdsupport wrote on Saturday, January 25, 2014:
This is in response to Brady’s request for alternative mechanisms -
We think deployment of zf2 or any other framework should be treated as primarily refactoring project while allowing concurrent deployment of new features using framework features exclusively (‘pure’ modules). In practical terms :
phase 1: Objective - Establish platform that supports concurrent operation of framework based code and legacy code
Establish zf2 application under https://emrserver/some_zf2_basedir and few mod_rewrite rules route https://emrserver/openemr requests to legacy code but https://emrserver// traffic is routed to zf2 module. Initial base module view could be as simple as a ‘Coming Soon’ display.
phase 2: Objective - Establish common services for new modules
Using globals established by legacy login, enable a base module that others can depend on to provide common services such as db link to openemr database, logging, mail, menus, debuggers etc…
phase 3: Objective - Refactor / New development
Refactor base modules code and other legacy code as modules or create completely new modules using services of other modules. This phase could talke considerable amount of time. Care is needed during this phase that modifications to legacy code use ajax/json to invoke new features.
phase 4: Objective - Discountinue legacy
When all desired functionality of the legacy codebase is available as pure modules, change mod_rewrite and eliminate legacy code.
When we had tried few approaches around time of zf2 release, we had working prototype of phase 1. It can be created with few command lines and edit of apache config in 10-15 minutes. If anyone is interested we can share that. However hard and crucial aspect of the process is designing common services as they need to implement same or better functionality but use the framework provided components. Consider logger - while it is tempting to write a record to a table, zf2 approach is to invoke logger/db which brings in logger. Logger then allows output to Firebug and/or console etc. Logger can be tied to events so the application can record the context of the database update as well.
sunsetsystems wrote on Saturday, January 25, 2014:
Regarding Brady’s licensing question, see:
https://www.gnu.org/licenses/license-list.html
As I read it, it looks like we’re OK if we consider the GPL licenses to be GPL3. GPL2 will not work with Affero v3.