ignoring autotool in debian/copyright?

Felipe Sateler fsateler at debian.org
Thu Dec 1 03:13:35 UTC 2011


On Wed, Nov 30, 2011 at 00:16, Jonas Smedegaard <dr at jones.dk> wrote:
> On 11-11-21 at 11:25am, IOhannes m zmoelnig wrote:
>> On 2011-11-21 03:26, Felipe Sateler wrote:
>> > Looks like there is a strange thing with the install-sh section in
>> > debian/copyright. The license name contains spaces, and doesn't
>> > match any License: paragraph.
>
> I guess what you find strange is license names of this form:
>
> License: GPL-2+ with Libtool exception
>
> That, I believe, is perfectly correct according to (latest drafts of)
> DEP-5.  Please elaborate what you find strange about it.

I do not know what is the current status of DEP5. What I found strange
was the use of spaces (which are otherwise used as separator) in the
license name.

>
>
>> > I'm not quite sure what is the dep5 way to deal with this. Most
>> > likely the exception should be moved into the license paragraph and
>> > the qualificators to the name (with X exception) removed.
>
> Yes, treating a license that contains an exception as a combined unique
> license is also allowed by DEP-5, but is less usable, as the underlying
> general license is then not machine-readable.
>
>
>> it seems that all those problems only come from the autotools
>> generated stuff, which is something where i have the feeling that it
>> should not create problems at all.
>
> I don't see no problems.
>
> Perhaps the "problem" you are talking about is the one of being
> cumbersome to properly document all these varying licenses for the code
> that be use?

The problem is spending too much time doing things that give little
gain. Plus, they also make the document less useful by adding unneeded
noise. The files are autogenerated, and they don't either end up or
"pollute" the binaries. This means they are of little use in the
copyright file (which is meant to document binary packages copyright).

>
> You are free to not use the code if you find that the burden of playing
> along with the rules of the game (which includes documenting licensing!)
> is higher than the benefit of using it.

Documenting licensing is not part of the rules of the game. The
copyright file is a necessity because the original documentation
(contained in the source package) is not shipped in the binary files,
so we condense that into a single file shipped in every package. There
is no point in documenting stuff that does not end up in the binary
packages.

>
>
>> i'm therefore wondering, what is the best way to deal with autotools
>> generated files in general.
>
> You can (with your Debian hat on, I am not talking about upstream here)
> repackage the source to *not* include the autogenerated files as part of
> Debian distributed sources.  IF the files truly are only autogenerated
> at the target build host you need not document it - but all that we ship
> in sources should be documented, whether or not it is used for the
> production of binary packages!

I disagree with the above. If something does not end up in the
binaries, it doesn't need to be documented in the copyright file.

>
>
>> so i asked at #debian-mentors (see end of this mail), with the
>> conclusion (as i read it), that it might probably be best to leave out
>> generated files from debian/copyright alltogether.
>
> I read that not as being "best" but being "tolerated".  The big unspoken
> truth is that Debian has a long way to go to properly document all
> licensing - and autotools is not the best place to start, as it is much
> work with little gain (covers little if any new licensing or authors).
>
>
>> would this be acceptable? for you? what do other think?
>
> Acceptable, yes.  But ripping out proper documentation as you just did
> now is completely backwards IMO!

It is unnecessary noise when trying to determine the licensing of
things in the binaries we ship, which is why I said it should be
removed.


-- 

Saludos,
Felipe Sateler



More information about the pkg-multimedia-maintainers mailing list