<div>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 todownload our old private datapacks without any form of authorization... </div><div>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...<br></div><div><
</div><div>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 managerof 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.</div><div><br></div><div>My
</div><div>Do you have any idea to progress with these legal/technical issues ?</div><div><br></div><div>Thanks</div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div><br></div><table width="351" cellspacing="0" cellpadding="0" border="0" style="text-align:left;border-collapse:collapse;border-spacing:0px;color:rgb(20,49,65);font-family:proxima-
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
The private data are only available to paying partners to the NPO.
Forks trie to access our private data using the open sourced server protocol (query to a php script).
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.
On Thu, Jan 9, 2020 at 8:00 PM Eric Maeker wrote:
Free Source code is provided to any demander approved by the NPO, codelicence 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 bythis 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 isstill 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 serverprotocol (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
La gériatrie, c'est la médecine pour les pères et les mères Noël</font></p></td></tr></tbody></table></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"Jan 9, 2020 at 8:00 PM Eric Maeker wrote:<br>
Le ven. 10 janv. 2020 à 03:03, Paul Wise <<a href="mailto:pabs@debian.org">pabs@debian.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu,
Hi,
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" ?
Belle journée
Cordialement
<http://maeker.fr> *Dr Maeker Éric*
*Gériatre, psychogériatre*
eric.maeker@gmail.com
Twitter @DrMaeker <https://www.twitter.com/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
Le ven. 10 janv. 2020 à 03:03, Paul Wise <pabs@debian.org> a écrit :
On Thu, Jan 9, 2020 at 8:00 PM Eric Maeker wrote:
Free Source code is provided to any demander approved by the NPO, codelicence 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 bythis 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 isstill 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 serverprotocol (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
</div><div>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.<br></div><div>Sounds like we are travelling to "contrib" or "non-free" package ? Or may be "non-debian" ?<br></div><div> <br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">
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.
Sounds like we are travelling to "contrib" or "non-free" package ? Or
may be "non-debian" ?
We know that at least two forks exists (this is what our private data server's log tells us). We do not receive any patch, invitation to
git repos, or any kind of official informations or queries.
we decide that our git repository will not be freely accessible.
Approval does only concern ... the ability to join the project as
member (coder, tester, communication manager...).
On Fri, 2020-01-10 at 17:34 +0100, Eric Maeker wrote:
We know that at least two forks exists (this is what our private data server's log tells us). We do not receive any patch, invitation to
git repos, or any kind of official informations or queries.
Having multiple forks and having folks not bother to send feedback is
normal in Free Software, especially for software that uses github.
There was a blog post about this recently but I'm unable to find it. I
would not worry about there being forks available, instead focus on the feedback that you do get and try to build a community around the code.
we decide that our git repository will not be freely accessible.
I encourage you to consider changing back to an open repository; as
Andreas has pointed out, this is already affecting other potential contributors and affecting potential redistribution of your software.
Approval does only concern ... the ability to join the project as
member (coder, tester, communication manager...).
This is normally how things work, you build up trust through your contributions to a project and then they invite you to join.
--
bye,
pabs
https://wiki.debian.org/PaulWise
I'm really sorry, but I can not answer to everyone and all your
questions. I feel a bit flooded.
About the website and the DFSG compliance, please consider that the
website translations are out of sync. FreeMedForms integrates now one
extra content : code128.ttf, that is not clearly licenced ( https://grandzebu.net/informatique/codbar/code128.ttf / https://www.dafont.com/fr/code-128.font). This is required for all
user who wants to print bar codes (see https://freemedforms.com/fr/news/versions/110#codes_barres)... This
is why the package is mentioned "not 100% DSFG compatible". But may
be we made an error (that anyone can correct) ?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 185 |
Nodes: | 16 (1 / 15) |
Uptime: | 134:44:39 |
Calls: | 3,758 |
Calls today: | 2 |
Files: | 11,180 |
Messages: | 3,469,232 |