Re: FreeMedForms projet

2020-01-11 Thread Paul Wise 
On Sat, 2020-01-11 at 17:08 +0100, Eric Maeker wrote:

> I'm really sorry, but I can not answer to everyone and all your
> questions. I feel a bit flooded.

Sorry about that, I hope one final email is not too much.

> 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) ?

According to the font metadata and the font website, the Code 128 font
is licensed under the GPL so is probably free. Since it is a separate
project to yours though, it should be packaged separately in Debian and
your package should then depend on it.

https://grandzebu.net/informatique/codbar-en/code128.htm

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: FreeMedForms projet

2020-01-11 Thread Eric Maeker 
Hi

I'm really sorry, but I can not answer to everyone and all your questions.
I feel a bit flooded.

What I can say is that we are working (in real life, I alone, because I'm
the only one to manage Debian in the project, we have macist only...) to
finish the code of 1.1.0 and release it like we always do : source packaged
and freely available, bins ok, tests ok. No buggy soft, no untested
features. Now that doctors use our soft and put all patient data in it, we
can not deliver a buggy software and we must test update from older version
before any release. This means time...

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) ?

All other extra-non-free content are only downloadable from our server
datapack (directly from the application) and users are well informed of all
licence and missing features (DDI management mainly). This choice goes
beyond the question of licenses since it also implies from managers of the
project medical and scientific responsibilities. This is also why we can
not accept that forks tries to download and install our private data.

We noticed that Popcon says:
*freemedforms-freedata* 62
While
*freemedforms-emr* 30
We understand that people are more interested by our data than by our
complete solution. This is not exactly what we thought at the start of the
project. Whatever, the project goes on!

I hope I made our choices clearer... You can consider that our engagement
in free software and specially in debian is still the same since 2008.

Belle journée
Cordialement


 *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


Le sam. 11 janv. 2020 à 02:15, Paul Wise  a écrit :

> 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
>

Re: FreeMedForms projet

2020-01-10 Thread Andreas Tille 
On Sat, Jan 11, 2020 at 08:39:48AM +0800, Paul Wise wrote:
> 
> The bigger problem for entering Debian is what Andreas mentions, that
> the software uses Qt4 instead of Qt5. Once you have released a new
> version that uses Qt5 it could potentially enter Debian.

To be correct: Version 0.9.4 in Debian is Qt4, but Version 1.0.0 in Git
is Qt5.  It just does not build successfully[1] ... and since monthes
nobody was able fix this.  Eric said he can not reproduce this build
issue (in private mail) and non of the Debian maintainers found a clue
so far.

Kind regards
 Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874880#104

-- 
http://fam-tille.de

Re: FreeMedForms projet

2020-01-10 Thread Michael Lustfield 
It looks like this bug went from "Qt4->Qt5" to "no longer DFSG-free."

On Fri, 10 Jan 2020 17:34:35 +0100
Eric Maeker  wrote:

> Oh! There is a misunderstanding here!
> Let me correct my words:
> -> full code of each stable released version is packaged and freely  
> available (but undocumented since v1.0.0).

From: https://freemedforms.com/en/downloads/root

"Downloads are 100% compatible with the Debian social contract."

From: https://freemedforms.com/fr/downloads/root (translated)

"Since v1.1.0, some files are available under a license incompatible with
the social contract of Debian . If you are looking for software 100%
compatible with this contract, please refer to v1.0.0."

Without digging in too deep...
- You mentioned documentation removal in 1.0.0
- This page mentions DFSG-freeness was broken in 1.1.0

If these were two distinct periods of time, that would lead me to suspect
additional files were added that broke compatibility with the DFSG.

> 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.

This could definitely be a language barrier problem, but I don't follow. Why
are you concerned about forks? If you have quality open source software, then
people will fork it. Sometimes patches will be sent back upstream, other times
they won't be.

Take a look here: https://people.debian.org/~bap/dfsg-faq.html
Particularly at 9a (The Desert Island Test)

Demanding that all modifications be shared with you very clearly fails this
test, and is not actually part of the license you applied to the software.

> In consequence, we decide that our git repository will not be freely
> accessible. Approval does only concern the FreeMedForms' git and the
> ability to join the project as member (coder, tester, communication
> manager...).

It's probably worth noting, a public repository is recommended, but not
required for inclusion in Debian repositories. However, inclusion of source is
an absolute requirement.

This "documentation" that was removed seems to be much more than just developer
docs; I'm unable to find any non-header comments in any file.

If you look at how javascript is handled, any minified version is considered
compiled source. You are essentially doing the exact same to your source when
you release it. It's not the actual source... it's just some partial version of
it. In this case, with intentional obfuscation.



This could still make it into non-free, however, I'd urge you to reconsider
your motivations for releasing obfuscated source and refusing to share. Is it
really your desire to make software that's (per DFSG) not free?


-- 
Michael Lustfield

Re: FreeMedForms projet

2020-01-10 Thread Paul Wise 
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


signature.asc
Description: This is a digitally signed message part

Re: FreeMedForms projet

2020-01-10 Thread Paul Wise 
On Fri, 2020-01-10 at 13:01 +0100, Eric Maeker wrote:

> Sounds like we are travelling to "contrib" or "non-free" package ? Or
> may be "non-debian" ?

The section of Debian a package is added to depends solely on the DFSG
compliance of the software (freely licensed and released source code).
Whether software is classed as non-Debian depends on the quality of the
software and on Debian having permission to redistribute the software.

https://www.debian.org/social_contract#guidelines

It sounds like your software is probably DFSG compliant but that you
have some organisational issues that are not best practice for a proper
 Free Software project. While I would encourage you to fix those
issues, they are by no means a requirement for your software to enter
Debian.

The bigger problem for entering Debian is what Andreas mentions, that
the software uses Qt4 instead of Qt5. Once you have released a new
version that uses Qt5 it could potentially enter Debian.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: FreeMedForms projet

2020-01-10 Thread Francesco Poli 
On Fri, 10 Jan 2020 04:18:26 + Paul Wise wrote:

> 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.

For what it's worth, I personally pretty much agree with all the
comments made by Paul in the previous two messages...

Thanks to Paul for expressing all the concerns and dislikes so clearly
and thoroughly.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpPXIcMmyi8F.pgp
Description: PGP signature

Re: FreeMedForms projet

2020-01-10 Thread Eric Maeker 
Oh! There is a misunderstanding here!
Let me correct my words:
-> full code of each stable released version is packaged and freely
available (but undocumented since v1.0.0).

Code is considered 100% stable (and released) when :
- it perfectly passes every the unit-tests in debug mode with MacOs,
Win32/64, Debian 64,
- it perfectly builds in each platform and
- it perfectly passes manual tests on the release bin for each platform.
Manual tests are available on our main website : freemedforms.com
-> This is because we do not have time to test and pack all sub-versions
like before.
Currently v1.1.0 does passes all tests under MacOs, does build correctly on
Debian in debug mode but not in release, and is not tested on Win32/64
(build process, unit-tests, installation process, config process...)
because WinDevs quit the project. So it is considered as a pre-version
available only to testers (MacOs).

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.

In consequence, we decide that our git repository will not be freely
accessible. Approval does only concern the FreeMedForms' git and the
ability to join the project as member (coder, tester, communication
manager...).

I hope that the situation is clearer for you.

Belle journée
Cordialement


 *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


Le ven. 10 janv. 2020 à 14:26, Daniel Hakimi  a
écrit :

> If the package is available under the GPL, it strikes me that requiring
> any non-trivial approval to obtain source under that license would not be
> allowed. If the form is just a check box verifying that you have received
> object code, maybe, but this sounds like it may be a license violation. Can
> we clarify what the approval process entails? How much information is
> required, and for what reasons might people be rejected?
>
> However, if some third party were to obtain this source, build from it,
> and make it available, that version of the code would be perfectly Free.
>
> On Fri, Jan 10, 2020, 08:15 Andreas Tille  wrote:
>
>> On Fri, Jan 10, 2020 at 07:45:34AM -0500, Daniel Hakimi wrote:
>> > Can you please clarify -- you said the license was the same, but you
>> didn't
>> > say what that license actually was. What license is your code available
>> > under?
>>
>> GPL-3+ [1]
>>
>> BTW, I think if a Debian package is published the requirement to sign
>> anything to get the source code is useless since interested parties can
>> easily download the Debian source package.
>>
>> This is for instance true for the latest source in Git which just has a
>> compile bug which we desperately try to fix to finalise the Qt4
>> removal[2].
>>
>> Kind regards
>>
>>   Andreas.
>>
>> [1]
>> https://salsa.debian.org/med-team/freemedforms-project/blob/master/COPYING.txt
>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874880#104
>>
>> > On Fri, Jan 10, 2020, 07:18 Eric Maeker  wrote:
>> >
>> > > 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
>> > >
>> > >
>> > >  *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
>> > >
>> > >
>> > > Le ven. 10 janv. 2020 à 03:03, Paul Wise  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,
>> 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,

Re: FreeMedForms projet

2020-01-10 Thread Andreas Tille 
On Fri, Jan 10, 2020 at 07:45:34AM -0500, Daniel Hakimi wrote:
> Can you please clarify -- you said the license was the same, but you didn't
> say what that license actually was. What license is your code available
> under?

GPL-3+ [1]

BTW, I think if a Debian package is published the requirement to sign
anything to get the source code is useless since interested parties can
easily download the Debian source package.

This is for instance true for the latest source in Git which just has a
compile bug which we desperately try to fix to finalise the Qt4
removal[2].

Kind regards

  Andreas.

[1] 
https://salsa.debian.org/med-team/freemedforms-project/blob/master/COPYING.txt
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874880#104
 
> On Fri, Jan 10, 2020, 07:18 Eric Maeker  wrote:
> 
> > 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
> >
> >
> >  *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
> >
> >
> > Le ven. 10 janv. 2020 à 03:03, Paul Wise  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, 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

Re: FreeMedForms projet

2020-01-10 Thread Daniel Hakimi 
Can you please clarify -- you said the license was the same, but you didn't
say what that license actually was. What license is your code available
under?

On Fri, Jan 10, 2020, 07:18 Eric Maeker  wrote:

> 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
>
>
>  *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
>
>
> Le ven. 10 janv. 2020 à 03:03, Paul Wise  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, 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
>>
>

Re: FreeMedForms projet

2020-01-10 Thread Eric Maeker 
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


 *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


Le ven. 10 janv. 2020 à 03:03, Paul Wise  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, 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
>

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