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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546cf767.1040...@debian.org