[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP-5: binary package affected by license $foo

On Wed, 04 Nov 2009 23:47:52 +0100
Frank Lin PIAT <fpiat@klabs.be> wrote:

> Hello,
> As I was updating the copyright file in a package, I wondered if it
> would be useful to add an optional header (named "Binary-Package" or
> whatever), to state which binary package is using that file and license.

You'll need a feed from something based on licensecheck from devscripts
so that source packages with thousands of source files can actually be
handled within any remote possibility of reason - and then tie that to
the target listings in Makefile.am and correlate those targets with
lines in the debian/foo.install files? Package splits are going to be
true nightmares.

'licensecheck' itself doesn't always find a licence in files that don't
use particular patterns for the position / comment layout of the
licence text. (IIRC it only checks the first portion of the file.)

Many, many source code files have no licence declaration within the
file itself but come under some arbitrary "collective" assignment which
could be distributed through various other LICENCE or COPYING or other
text files. Directories cannot be taken as only containing files of one
licence either.

Now maintainers need to correlate that moving target with the
changes within individual source code files and within target listings
in Makefile.am and correlate those with the assignments in the
debian/foo.install files?

> The rational is that sooner or later, we will want to use the
> machine-interpretable copyright file to validate packages freeness,
> license compatibilities and so on.

 ... which would only be useful if all (or at least a majority) of
packages were able to create *and maintain* this complex map of licence

Sounds very far fetched to me - and I don't even have any particularly
large source code packages to maintain (just quite a few small to
medium ones).

I wouldn't do this for packages where I am both the Debian maintainer
and the sole upstream developer! (I'd hesitate to even do it for the
simplest native Debian packages that haven't needed large scale updates
since Etch.)

The problem is not obtaining the raw licence data - every maintainer has
to review this data when creating the first package - it is maintaining
that meta-data *and mapping it to individual executable targets and
further to the packages into which those executables are assigned*
through upstream releases across thousands of source code files. These
things are not tracked in the upstream ChangeLog, remember.

This sounds like just as much work as trying to collate a unique and
accurate list of Copyright holders that started the last flame war
about DEP5.

So upstream adds a single line to a C file, deep in the bowels of a
large package, adding a header file from elsewhere within the same
source package and now the Debian maintainer is meant to not only notice
but check the licence for the code referenced in that header file and
update debian/copyright????

If I add a new file to an existing binary package because the new
upstream version builds something useful, I have to research where
*all* the code came from to create that file and might have to update
debian/copyright for that one file???

If upstream add a file that isn't ready for release and isn't going to
be packaged - maybe it's even deleted in the clean target of
debian/rules - I still have to update debian/copyright???


Can you even imagine how complex this would be for something like gcc
which builds more binary packages than I care to count?


Neil Williams

Attachment: pgprvT40QW1xG.pgp
Description: PGP signature

Reply to: