Re: FreeMedForms projet
For now, our NPO is too poor to engage in consulting or to pay external developments and we awfully miss time to manage all aspects of a widely collaborative project.
Sounds like we are travelling to "contrib" or "non-free" package ? Or may be "non-debian" ?
La gériatrie, c'est la médecine pour les pères et les mères Noël
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.
> 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.