We’re having a conversation on CSM-86 that I’d like some broader input on.
Is it okay to include a library that is free for non-commerical use, but otherwise costly, in a module that is bundled with the reference application?
(In this specific case we’re talking about using Highcharts in the Chart Search Module, and they count Government as commercial, so my not-a-lawyer interpretation is that someone would then need to pay Highcharts if they want to use OpenMRS in a government health facility.)
My personal opinion is that the reference application must be able to work legally out of the box anywhere for free. I’m curious whether anyone has a different take.
So, from my perspective, the options would be:
Contact Highcharts and see if they will give OpenMRS a free OEM license. (I believe that KenyaEMR got this, so it should be possible. @michael would your team take care of this?
Don’t use Highcharts in the Chart Search Module.
Remove the Chart Search Module from the reference application, and let people install it themselves as an add-on module. (And the module repo needs to sufficiently document when the module can/can’t be used for free.)
Alternately, perhaps we could still include it, but have some sort of “disabled until admin confirms licensing” state for the module.
What I don’t know off-hand is how compatible this is with our MPL 2 + HD licensing.
Regarding the OEM license, I assume that’s their own custom-written agreement and we’d have to see a copy of it to understand whether or not it was compatible with MPL 2.
I’m a big fan of Highcharts. They’re elegant and make interactive charting very easy.
While I agree that OpenMRS’ reference application should be free for anyone to use, I don’t believe that OpenMRS needs to be free for anyone to sell – i.e., if someone wants to sell commercial copies of OpenMRS, then they need to deal with licensing issues like this. That’s life. For example, they can either omit the module(s) that use Highcharts or they can incorporate the licensing fees for Highcharts into their business model.
Per their FAQ, we could bundle Highcharts for offline use as long as we informed people (e.g., via README, LICENSE, and/or NOTICES in source code and on the download page for OpenMRS & the module) that the graphs use Highcharts, which is free for their use, but not free for commercial use, pointing them to the Highcharts website for more info.
To make licensing choices easier for OpenMRS, you should look for them on the Open Source Initiative (OSI) list of “open source” licenses.
Non-commercial but free licenses aren’t open source. The Highcharts software isn’t open source.
This has nothing to do with Highcharts being great software. But if OpenMRS has made the choice to be free and open source, you need to be consistent in your in-licensing. Either negotiate a different license from Highcharts, or try to find another program.
Of course people implementing organizations should be able to sell OpenMRS, and they should have to deal with the licensing ramifications of this.
My point is that the #1 priority should be that anyone who downloads the OpenMRS-produced reference application can use it for free without having to do anything additional to use all bundled features. That means, for example, that we cannot include the SNOMED CT reference terminology, and would require people to install it themselves (and ensure they are in compliance with any related licensing).
I think that a “commercial or government” run health facility should be able to download the OpenMRS reference application and use it out of the box for free also. I.e. if you get the official distro from the OpenMRS website, it shouldn’t matter who you are, you should be able to use it for free. Hence the specific options I suggested.
This was the same rationale for Mozilla moving away from Highcharts and to d3 for its Market place and eventually AMO products, and I agree 100%.
We can certainly approach Highcharts about a special license, but for sustainability I think we need to make sure we’re not starting with a pre-determined solution before looking at all the alternatives.
Approaching Highcharts for a special license sounds much a better thing, i have been trying to consider any available similar open source options and found none to better replace it. http://dygraphs.com/gallery/#g/dynamic-update is one option though i personally did not prefer it’s way of supporting zooming the other was http://sigmajs.org/ which i have not yet established if it supports our needs, most of the others are not free at all, looks like High-charts is better than all of them for our requirements
Is there a list of requirements for the charting tool other than “support zooming in and out to see details” which AFAICT is the only one mentioned in CSM-86?
Flot and d3 are probably the biggest players in this space and they are both free & open source, as well as support zooming.
(The email-to-talk parser ate some of my last message, which said…)
Also, I’m curious what level of graphing is actually going to happen in the chart search module. There are lots of libraries on top of d3 that I’ve read generally positive comments about (c3, rickshaw, vega, nvd3) and I imagine that any of those tools are as good as highcharts for our purposes.
As an open source project, OpenMRS shouldn’t use terms like “free” too loosely, I copy below an email from Patrick Masson of Open Source Initiative (OSI) describing such licenses: You may find this helpful. /Larry
Interestingly, as this appears to be increasing (i.e. governments/agencies looking to adopt “open source software”) we have begun cataloging policies/laws that cite the OSI and OSI Approved Licenses as a determiner of software being open source or not. This is here: International Authority & Recognition – Open Source Initiative
There are many more, but we have yet to capture them all. This is a summer intern project
My (personal) opinion is that it’s fine if the OpenMRS reference distribution contains some closed-source content and/or libraries, as long as there’s a broad grant allowing these to be used free in the OpenMRS context.
(That said, I prefer if we can use an equivalent open-source approach.)
I would love to hear about a javascript library that can hold a candle to Highcharts. Simple, beautiful, interactive, intuitive features, SVG with fallback to javascript, … the list goes on. What’s not to like?
Hopefully there’s something that’s in the ballpark. All of the other javascript charting libraries I’ve seen pale in comparison, producing limp, static charts that belong in the last century.
Exactly, we should pick the library depending on the type of graph but also the particular skills of the developer. D3 seems low level and requires a lot of JS coding, and probably good math knowledge (geometry).
At work I use FusionCharts which is old and Flash based (at least the free version) but for basic charts there’s enough populating a JSON structure, it’s dead simple.
In that context, I confess of having miss-used the term requirements, the problem to solve is precisely what you are here mentioning @michael ; though I think scrolling from left to right can be replaced by a better zooming solution than selection of a section of the graph to see the details.
I have tried to look into most of these open source line chart alternatives while comparing them with what we are currently using ( http://omnipotent.net/jquery.sparkline/#s-about ) and so no big addition as high-charts would actually make, and so, i have for now passed over this issue until we agree on the best choice.
@dkayiwa, i don’t what you have to say about this issue in comparison to:
I (still) maintain that it is not acceptable to use Highcharts in a module that is bundled in the reference application, because that means a “commercial or government” run health facility" cannot legally download the default OpenMRS release and use it.
So the options are (rephrased from an earlier comment in this thread):
Don’t do anything now, and deal with this later
Don’t use Highcharts in the Chart Search Module.
Remove the Chart Search Module from the reference application, and let people install it themselves as an add-on module. (And the module repo needs to sufficiently document when the module can/can’t be used for free.)
Make a change to the openmrs-core module framework to require the user to accept licensing before the module is allowed to start for the first time.
