Re: Is tabular data in binary format acceptable for Debian ?
Le Thu, Jan 21, 2010 at 06:14:15PM -0800, Steve Langasek a écrit :
> reading your message made me worry that the ftp team were moving the
> line for archive acceptance without discussion, when reading the bug log
> shows that they're simply trying to determine on which side of the existing
> line these files fall.
>
> I would suggest that you add documentation to the source package in
> debian/copyright
The archive administrators are trying to determine if the files are DFSG-free,
have asked three times more information (here is the third time
(http://lists.alioth.debian.org/pipermail/debian-med-packaging/2009-December/005336.html)
and despite all our answers are not giving their conclusion. It is my opinion
that if their conclusion is that the file is non-free, they move the line for
archive acceptance.
The whole thread can be stopped by one member of the FTP team writing ‘Go
ahead, these files are free.’ As I demonstrated earlier, there are too many
human errors to take the acceptance of the package as a silent confirmation
that the files are free. Also, the next upload may contain some ASCII dumps of
the tables, just in case. So we may not be able to conclude.
I do not see why we would need to add extra information in debian/copyright (by
the way, aren't we suppose to work on a format that helps the maintainers to
waste less time with that file?). If such a documentation were necessary for
r-cran-epir, why would it be dispensable for the other packages in the archive,
like r-cran-rocr ? Also, shall we add one for the PDF documentation as well ?
The archive administrators did not find their source at the first review…
We do need clear answers and guidelines to acheive consistency, that puts some
sense in our efforts. If it is an archive-wide request to add a disclaimer for
the .Rdata files that contain tables, explaining that despite being part of
Debian they are not non-free, I will obey despite disagreeing. But just making
and ad-hoc rule that applies to only one package does not make much sense in my
opinion.
Lastly, it is relevant that these files are not intended to be modified: as
reminded by Don, it is contrary to the idea of free software if the upstream
authors would keep for themselves a file that facilitates the edition of one
component of the software. For components that are not expected to be modified,
who cares if it at the first modification (and only the first) it takes half an
hour instead of ten minutes? My experience of long-term relations with
upstream is that they start on much better grounds if we contact them with good
news about the distribution of their works or with useful patches, rather than
with futile requests.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: