Bug#743532: lintian: when to say: old-fsf-address-in-copyright-file
Hi,
On Thu, Apr 03, 2014 at 06:45:25PM +0200, Jakub Wilk wrote:
> * Osamu Aoki <osamu@debian.org>, 2014-04-04, 01:16:
> >License: GPL-2.0+ with incorrect FSF address, and with autoconf exception
>
> FWIW, this line does not conform to the copyright format specification.
What is the offending part? "GPL-2.0+" or "with ..."?
"GPL-2+" and the SPDX style "GPL-2.0+" are equivalent as specified as
"For SPDX compatibility, versions with trailing dot-zeroes are
considered to be equivalent to versions without (e.g., "2.0.0" is
considered equal to "2.0" and "2").".
As for "with ..." part, I am following "An exception or clarification to
a license is signalled in plain text, by appending with keywords
exception to the short name."
I wish to fix problem here. Please let me know the solution.
(As I re-read spec, I realize my MIT license marking needs to be fixed
to use Expat if it is not X style.)
> >For me copying "license" text including some associated disclaimer exactly
> >from the original source seems to be the right thing to do.
>
> Indeed. But the main point of old-fsf-address-in-copyright-file is to let
> you know about _upstream_ problem.
Then please use "I: instead of "W:". Warning seems excessive when the
maintainer is aware and tracking its status by marking it in here.
> >FYI: This debian/copyright is autogenerated here using debmake packaging
> >helper script.
>
> If the copyright file was automatically generated, then there's even greater
> change that you didn't notice the problem yourself.
To be clear, only a template of debian/copyright is autogenerated to
save time for maintainer checking the same license text in different
files word-by-word. Maintainer needs to give final touch which I made it
clear in its documentation.
Most of these trouble comes from autotools. That is why almost no one
bothered to list such problematic files in this debian/copyright and
they evade annoying warnings by treating such files as a part of *. I
was surprised to see so many autotools derived files had this problem.
By documenting all files properly with the help of program and marking
their problems obvious, next automatic license check run of the source
tree may find it has been fixed upstream too. Then he can update
debian/copyright.
(Right now debmake only creates the template file only. It can not verify
existing debian/copyright against updated source tree yet.)
Osamu
Reply to: