Re: FreeMedForms projet

2020-01-09 Thread Paul Wise 
On Fri, Jan 10, 2020 at 2:02 AM Paul Wise wrote:

> I don't like this, people seeking source code should not have to get
> approval first. That said, I note that the source code is available
> directly from the site without approval.

I missed seeing that the git repository containing the source is
private. I don't like that, development versions and the development
process should be public and allow external people to participate.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: FreeMedForms projet

2020-01-09 Thread Paul Wise 
On Thu, Jan 9, 2020 at 8:00 PM Eric Maeker wrote:

> Free Source code is provided to any demander approved by the NPO, code 
> licence is still the same.

I don't like this, people seeking source code should not have to get
approval first. That said, I note that the source code is available
directly from the site without approval.

> But, the code documentation is only reserved to approved developers by this 
> NPO.

I definitely don't like this, it would be much better to publish the
code documentation to everyone under a free license.

> We do encourage new dev to apply to our NPO and to sign a CLA (which is still 
> a draft piece of text actually).

I don't like this either, it would be much better for devs to release
their contributions under the same license that you do, then you can
incorporate their changes, preserving their copyright over their
changes and passing on their license to you to downstream users. So
the whole of the software is then owned by a variety of copyright
holders, each of whom also have to abide by the license given to them
by the other contributors. The license on the software then cannot be
changed without contributor consensus, so it becomes a much more solid
project from a user perspective. Single-owner projects are much more
easy to turn proprietary.

http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html

> The problem is that FreeMedForms EHR needs access to private data

Could you explain why this data needs to be private? It would be much
better to release it publicly under a free license.

> The private data are only available to paying partners to the NPO.

Is this the only form of income that the NPO has available to it? It
sounds like the NPO is seeking what is called an "Open Core" business
model, where the core part of the project is public and freely
licensed but addons are proprietary. The incentives here can be quite
perverse, often companies seek to prevent outside contributions to the
core or even remove features from the core so that more people start
paying them for the proprietary addons. So I encourage you to consider
alternative income streams.

I think the best option for the would be to consult with as many of
the practices, clinics, hospitals and emergency departments that you
know about that use the software and find out the best way for the NPO
to have enough resources to continue development consistent with the
interests of the community of folks who use the software. Examples of
potential income models could include: large grants/sponsorships that
cover development and other costs, a membership subscriber base that
pays for all maintenance and development costs, or more of a
crowd-funding model where folks interested in specific features pay
for their development, or a community of consultants that do all work
on the project as requested by their customers or possibly a
combination of these and other options.

> Forks trie to access our private data using the open sourced server protocol 
> (query to a php script).

I would suggest to just make the data public and under a free license,
but if you don't want to do that, the way to go would be to setup an
e-commerce site where people have to pay before they can download the
private data and then have in the software a way to load the locally
saved data that has been downloaded from the site. I believe there are
some freely licensed e-commerce tools in Debian and the consultants
that offer support for Debian in your area might be able to help with
finding, installing and configuring them.

https://www.debian.org/consultants/
https://lists.debian.org/debian-consultants/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

FreeMedForms projet

2020-01-09 Thread Eric Maeker 
Hello everyone,

In introduction to this mail, let me introduce FreeMedForms (if you already
know it, read next paragraph). FreeMedForms is an open source EHR with a
complet drug-drug drug-patient interactions (DDPI) checker. It is a full
set of two apps : freemedforms-ehr and freediams. FreeDiams is the
prescriber assistant plugin of FreeMedForms build into a full complete
application. FreeMedForms is maintained by a french non profit organization
(https://freemedforms.com/fr/asso/start) (association loi 1901). Free
Source code is provided to any demander approved by the NPO, code licence
is still the same. But, the code documentation is only reserved to approved
developers by this NPO. We do encourage new dev to apply to our NPO and to
sign a CLA (which is still a draft piece of text actually).

The problem is that FreeMedForms EHR needs access to private data to
manage DDPI and for some medical forms (some are free, some are not). The
private data are only available to paying partners to the NPO. FreeMedForms
can fully work with free data but without the DDPI and some printing
features.

As FreeMedForms is open source and is forked. Forks trie to access our
private data using the open sourced server protocol (query to a php
script). According to the server's log, we believe that at least two forks
are still trying to download our old private datapacks without any form of
authorization...
We tried SSH access and crypt the data with a private key to share with our
paying partners, but we do not have (time and) competences to do/manage
this...

We know that FreeMedForms is used in eastern europe, spain, france, russia,
argentina, some part of africa and may be other countries (china, uruguay,
brasil). Two clinics use it in their emergencies department. And I'm, as
main manager of the project and as president of the NPO, convinced that the
FreeMedForms project has its place in the Debian and also that the NPO
should focus on keeping FreeMedForms as a strong competitor in the field of
open source EHR.

My time to discuss legal and technical issues, code or support about the
project... is really weak as I'm a much more than full time MD, father,
writer, NPO manager, trainer of doctors, nurses and psychologists, etc...

Do you have any idea to progress with these legal/technical issues ?

Thanks


 *Dr Maeker Éric*

*Gériatre, psychogériatre*
eric.mae...@gmail.com
Twitter  @DrMaeker 
RPPS 10002307964

maeker.fr  Site personnel
empathies.fr  Association Emp@thies
freemedforms.com  Logiciel médical

La gériatrie, c'est la médecine pour les pères et les mères Noël