Re: DEP-5: binary package affected by license $foo
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
Reply to: