Re: policy regarding redistributable binary files in upstream tarballs
On 19/11/14 19:19, Salvo Tomaselli wrote:
> Generic question. In my experience some upstream include some redistributable
> binary files. For example some binary stuff to create a .app on osX, minified
> javascript, and whatever.
...
> - these files are redistributable, so there is no legal problem in hosting
> them on debian
> - these files are not installed nor used in the build process on debian, they
> are just inside the upstream tarball.
For main, they must be distributable under a DFSG license and they must
"include source code" (DFSG §2).
The precise meaning of "source code" is debatable and involves applying
some common sense. I believe the consensus is that they are OK if any of
these is true:
1. They are in the preferred form for modification ("the source"), or if
the preferred form for modification is unknown or not obvious, they must
be in a form that is a reasonable basis from which to modify them
(example: pak0/sound/* in openarena-data do not appear to have any
separate source files, and a .wav file is certainly something you can
edit, so we have assumed that they are their own preferred source)
2. They are not the source form, but the tarball also contains that
preferred form
(example: in openarena-data, the source for pak0/icons/icona_plasma.tga
seems to be source/assets/2d/2D improvement/icona_plasma.svg)
3. The upstream tarball does not contain the source, but the Debian
tarball does (typically in debian/missing-sources)
(example: lots of webapps have un-minified versions of bundled
JavaScript in debian/missing-sources)
To be sure that files are not used by the build, it can be a good idea
to delete them before building.
The rest of this email doesn't necessarily apply to you because you've
stated that the files do not get used in the build or end up in the
.deb, but for completeness:
In situations 2 and 3, it is preferred but not mandatory to re-generate
the "binary" from the corresponding "source". IMO, we have to be
realistic about this: if upstream doesn't have a build system and
exports the data into a compressed or simplified form via some manual
steps, perhaps in a GUI (hello OpenArena developers!), a prospective
Debian maintainer shouldn't be responsible for inventing an automated
build system (unless they want to, of course), particularly if in
practice the data file is going to be created once and never modified
thereafter.
For executable code that will be used during the build or end up in the
.deb, it is rather more important to verify that the "binary" actually
corresponds to the claimed "source", for two reasons:
* if it doesn't, and it's executed on a user's or developer's system,
it could do something harmful even though the (claimed) source code
is benign
* it's considerably more likely to have an urgent and/or non-obvious
bug that will need to be fixed via a Debian patch later
If executable code is accompanied by source but not actually recompiled
from it, I think that's a QA, maintenance and trust problem, potentially
a very serious one (I think the ftpmasters put this under the heading of
"fails to build sanely from source"?) but not necessarily a DFSG
problem. Others might not agree.
Regards,
S
Reply to: