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 <firstname.lastname@example.org> 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
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
> On Fri, Jan 10, 2020, 07:18 Eric Maeker <email@example.com> 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
> > <http://maeker.fr> *Dr Maeker Éric*
> > *Gériatre, psychogériatre*
> > firstname.lastname@example.org
> > 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 <email@example.com> 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