LibreHealth EHR License What is the best choice


(Terry Hill) #1

We, the group with LibreEHR, are trying to decide on the license to add to the code. Should there be a block at the beginning of each source file? What should we license under, there has been some talk about using the Apache version.

Any and all guidance is greatly appreciated.

Tony asked that I @lrosen


(Lawrence Rosen) #2

Is there a problem with using MPL-HD, as we do with most other LibreHealth software?


(Tony McCormick) #3

Worth considering, no one in the LibreEHR group even knows what that is though. :slight_smile: Apache seems to be the license of preference for most projects that could have commercial / vendor communities. But OpenEMR (where we come from) used GPL 2 and 3. This is an opportunity to discuss this, make a new choice and figure out how to deal with the code that we have inherited that is already GPL.


(Robby O'Connor) #4

You can read the license here, yes I am linking to the OpenMRS site, nobody sees access logs but the infra team and the core infra team is behind LH :slight_smile:


(Tony McCormick) #5

Here’s the direct link: https://www.mozilla.org/en-US/MPL/2.0/


(Terry Hill) #6

Is that what we want to use if so I will start working on the header for it.


(Tony McCormick) #7

MPL 2.0 is compatible with GPL. Exhibit A and B in the link have the header samples. I think this is fine, myself.


(Terry Hill) #8

Sample Header

/**

  • Patient Tracker (Patient Flow Board)
  • This program displays the information entered in the Calendar program ,
  • allowing the user to change status and view those changed here and in the Calendar
  • Will allow the collection of length of time spent in each status
  • Copyright © 2016 Terry Hill terry@lillysystems.com
  • LICENSE: This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0.
  • This program is distributed in the hope that it will be useful,
  • but WITHOUT ANY WARRANTY; without even the implied warranty of
  • MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  • Mozilla Public License for more details.
  • If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.
  • @package LibreEHR
  • @author Terry Hill terry@lilysystems.com
  • @link http://www.libreehr.org
  • Please help the overall project by sending changes you make to the author and to the LibreEHR community.

*/


(Robby O'Connor) #9

@tony, my link also showed the Healthcare Disclaimer that protects developers from legal action.


(Saptarshi Purkayastha) #10

I agree, adding the health disclaimer is a good idea!


(Robby O'Connor) #11

The perk of the Healthcare Disclaimer is that developers are are not held legally responsible if something happens to a patient. This is important for a Health IT project!


(Art Eaton) #12

And do we have an internationalization for the disclaimer schema? What is our Mouth of Wisdom (Legal Pro) saying about this? Finally, should we not ensure that the contents of our disclaimers, privileges and immunities clauses are merged, cover all LibreHealth related products and activities, and are sourced in all materials from a central repository all of it’s own? Meaning: Legal team updates, no-one else is allowed to modify it, and the contents are pulled from this repository (or read from there) from all products.


(Robby O'Connor) #13

@lrosen is probably the best person to answer this when he has the time to do so :slight_smile:


(Terry Hill) #14

Is there going to be an Issue mixing MPL with the GPL licenses on the legacy code? @lrosen


(Lawrence Rosen) #15

The word “mixing” is ambiguous. As long as you merely aggregate those two programs, there is no issue and the two works stay separately licensed (one under MPL, the other under GPL). If you combine the programs as a derivative work of both, then the result must be licensed under the GPL.

Stick with aggregation and you’ll have no problems.

/Larry


(Terry Hill) #16

If I have this correct I will need to include a GPL license for the legacy code and the MPL license.


(Art Eaton) #17

Licensing seems to always be a big aggregation for us.


(Terry Hill) #18

@lrosen would this header work?

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

Copyright © 20xx, MPL Contributor1 contrib1@example.net

Alternatively, the contents of this file may be used under the terms of the GNU General Public License Version XX, as described below:

This file is free software: you may copy, redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version XX of the License, or (at your option) any later version.

This file is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.


(Robby O'Connor) #19

Add the healthcare disclaimer…I don’t think of us want to get sued, or LibreHealth itself be sued.


(Lawrence Rosen) #20

Terry, this would be correct except for the word “alternatively.”

Assuming you are doing an aggregation, the MPL portions are licensed under the MPL and the GPL portions are licensed under the GPL. Permanently. Separate components, separate licenses for each component – for aggregations.

It turns out that the MPL license also contains a provision that the MPL software components can be distributed “alternatively” by downstream re-distributors under the GPL. (The GPL license contains NO equivalent provision!) This MPL-to-GPL provisions is not important for us but may be valuable for certain re-distributors of LibreHealth software who prefer the GPL to the MPL for the LibreHealth software versions that THEY distribute. It doesn’t apply to us ourselves because we always choose the MPL for software versions that WE distribute.