Re: FreeDiams 0.6.0 - excluding drugs database for the package ?
On Thu, Nov 17, 2011 at 12:39:11PM +0100, Eric MAEKER wrote:
> > You were mentioning four PD databases but the Belgium drugs database
> > says "unknown". This license should be clarified otherwise it is simply
> > non-free and this non-free license of a part of the file master.db makes
> > the whole file non-free.
>
> Well the site does not mention any license...
... which is non-free. What we need is an *explicite* free license.
For example after > 10 years we finally got rid of the molphy package
(which was worth removing not only because of the broken license.) It
had only one statement: "I *plan* to release the code as GPL." Then the
author vanished (= did not answered any more). This is non-free because
there is no license (even if the intention of the author was somehow
clear.)
> > Moreover I would really prefer to see the source data files shipped
> > inside the FreeDiams source tarball and create the database in the build
> > process.
>
> Impossible, the build process requires user interaction and checking.
Well, I have no idea about this but I would love if users would be
served with the tools needed to do this work somehow. This is no
requirement but would be some bonus we could provide.
> > This makes things much more transparent and would make it
> > quite simple to leave out non-free parts like the Belgium database.
>
> I don't understand why this would be a solution to non-free package till the database will hold the same licensing problems.
In Debian non-free you can find several packages with licensing problems
like "free for academic use" etc. The problem is that packages which
Depend / Recommend such non-free packages need to go into Debian contrib
(which is also out of main Debian).
> > In addition there might be bug reports (in whatever form) which needs us
> > to fix something inside the database.
>
> Database must be left unchanged at each release. There are no fixes for these database. They are updated at ech release of FreeDiams/FreeMedForms. Bugs will be fixed with nex upstream only.
If the build process needs manual intervention anyway this is OK.
> > I learned that this is close to
> > impossible when dealing with the wordnet package which I originally
> > maintained on the basis of preprocessed data. I needed to go back and
> > to provide the original source of the database to fix spelling errors
> > etc.
>
> No solution for that part.
> Or exclude the drugs database from the package and let user download the master.db from my personnal server. This leaves the bug fix to the FMF team and not to Debian teams.
As long as master.db can not exclude non-free parts we should consider
this.
> > This "one of our app" is the cruxial point here: What kind of app,
>
> Called FreeToolBox, actually heavy alpha :) segfaulting one to two times :D
>
> > where is the source
>
> FreeMedForms SVN trunk.
If you ask me this could be documented in a file
debian/freediams.README.Debian
with a short description where you can find these files and how to use
them.
> > and how can I reproduce this database building
> > process.
>
> With chance:
> - download sources
> - compil sources
> - no support provided 'till it is alpha
No problem with this.
> > Kind regards and thanks for the license clarifications
>
> That's not a funny work to check license. And I discovered that many site does not clearly notify the license of their data.
Yes. That's the hardest part in packaging. We love to find technical
solutions and are forced to understand texts written by lawyers.
> Thanks-pong
Thanks-ping
Andreas.
--
http://fam-tille.de
Reply to: