Re: FreeMedForms projet

[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

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