DEP-5: binary package affected by license $foo

[Frank Lin PIAT]

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.

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.

Some sample scenario:

Exemple 1:
> File: doc/info/*
> License: GFDL-NON-FREE
> Binary-Package: none
The package contains a file covered by a not-so-free license, but
that file isn't used to build the binary file. And the file isn't
shipped in the binary files.


Exemple 2:
> File: foo.c
> License: GPL-2
> Binary-Package: foo
>
> File: bar.c
> License: GPL-3
> Binary-Package: bar
The source package contains some files covered by two incompatible
license, but it isn't a problem because the binary aren't combined at
build nor at link time (or example).

Exemple 2:
> File: foo.c
> License: GPL-2
> Binary-Package: foo
>
> File: doc/info/*
> License: GFDL-NON-FREE
> Binary-Package: foo-doc-is-non-free
The source package produces both a free and non-free package.


This extra header would be completely optional, and only useful to
white-list some specific situation.

That's just an idea (a foolish idea?)

Franklin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Neil Williams-4]

On Wed, 04 Nov 2009 23:47:52 +0100
Frank Lin PIAT <fpiat@...> 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
meta-data.

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???

WHY?

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
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

[Ben Finney-5]

Frank Lin PIAT <fpiat@...> writes:

> As I was updating the copyright file in a package, I wondered if it
> would be useful to add an optional header

There is only one header in a DEP-5 copyright file. I think you mean
“add an optional field to the Files section”.

> (named "Binary-Package" or whatever), to state which binary package is
> using that file and license.

> 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.

Interesting. So you think a single source package could produce binary
packages that are each judged differently for their DFSG status? I
wonder what the FTP masters would say to that.

(That could read sarcastically; it's not. I'm interested to know.)

--
 \      “Shepherds … look after their sheep so they can, first, fleece |
  `\   them and second, turn them into meat. That's much more like the |
_o__)      priesthood as I know it.” —Christopher Hitchens, 2008-10-29 |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Robert Collins]

On Thu, 2009-11-05 at 13:59 +1100, Ben Finney wrote:

>
> > 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.
>
> Interesting. So you think a single source package could produce binary
> packages that are each judged differently for their DFSG status? I
> wonder what the FTP masters would say to that.
>
> (That could read sarcastically; it's not. I'm interested to know.)

I don't know what the FTP masters will say, but it is, sadly, how
licences interact; given a single upstream that builds two binaries, one
which links to a GPL library, and one that doesn't (and which are
packaged into separate debs), then we've clearly got different
constraints placed on the two debs.

-Rob

[Gunnar Wolf]

Frank Lin PIAT dijo [Wed, Nov 04, 2009 at 11:47:52PM +0100]:

> Exemple 2:
> > File: foo.c
> > License: GPL-2
> > Binary-Package: foo
> >
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: foo-doc-is-non-free
> The source package produces both a free and non-free package.
>
> This extra header would be completely optional, and only useful to
> white-list some specific situation.
>
> That's just an idea (a foolish idea?)

Leaving aside what Ben Finney and Robert Collins also replied to your
message... I do not believe this to be doable at all.

Packages in main should have their source packages in main. But if the
source package has non-free components, then it cannot be uploaded
into main. Even if the non-free components are not packaged, in order
to be in main they need to be stripped out of said components (and,
say, repackaged with +dfsg version)

Of course, you could perfectly have source packages in main generating
binary packages both in main and in contrib - But the licenses for the
sources' components would all be GFDL-free anyway.

--
Gunnar Wolf • gwolf@... • ([phone] / 1451-2244


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Wed, Nov 04, 2009 at 11:47:52PM +0100, Frank Lin PIAT a écrit :

>
> Exemple 1:
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: none
> The package contains a file covered by a not-so-free license, but
> that file isn't used to build the binary file. And the file isn't
> shipped in the binary files.
>
>
> Exemple 2:
> > File: foo.c
> > License: GPL-2
> > Binary-Package: foo
> >
> > File: bar.c
> > License: GPL-3
> > Binary-Package: bar
> The source package contains some files covered by two incompatible
> license, but it isn't a problem because the binary aren't combined at
> build nor at link time (or example).
>
> Exemple 2:
> > File: foo.c
> > License: GPL-2
> > Binary-Package: foo
> >
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: foo-doc-is-non-free
> The source package produces both a free and non-free package.

Hello Frank,

I think that we are still far from producing copyright files specific to binary
packages, but definitely, let's be careful to not close doors, and if we can
open some at low cost it is welcome of course. Also, there is nothing in the
Policy that prevents maintainers to start doing this with their package if
they feel like experimenting:

  Every package must be accompanied by a verbatim copy of its copyright and
  distribution license in the file /usr/share/doc/package/copyright. This file
  must neither be compressed nor be a symbolic link.

My understanding is that if source package S produces binary packages A and B,
/usr/share/doc/B/copyright does not need to describe the copyright of the files
in A.

This said, I think that we must care that copyright files are equally readable
by humans and machines, and easy to produce. So even if the field you propose
is optional, I think we need to consider how the copyright file would look like
if its use were widespread. Also, maybe we can acheive a similar result without
the using a new field, with an appropriate combination of control sums and
helper files.

Such a system could become a good safeguard against the inclusion of files that
are not free in the wrong package. Note that it is not an issue for the moment
as 1) non-free files are not allowed in the source packages, and 2) a source
package in main can not produce a binary package for contrib or non-free. The
field you propose could be an instrument for changing this, but I am affraid it
is not on the agenda, and is not likely to become so in the near future (even
if I would love to).

In summary, I think that your proposition is quite ahead of its time, but I would
have nothing against a ‘Future directions’ addendum to DEP-5 that would contain
such a field after it has been more throroughly thought.

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

On Sat, Nov 7, 2009 at 11:19 PM, Charles Plessy <plessy@...> wrote:

> I think that we are still far from producing copyright files specific to binary
> packages

There are already copyright files in binary packages that are
different to the source package debian/copyright; some of the source
packages I've created contain debian/copyright and
debian/foo.copyright because parts of the source package are not used
in the binary package. It isn't much of a stretch to put
debian/copyright, debian/foo.copyright and debian/bar.copyright.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...