-
-
Notifications
You must be signed in to change notification settings - Fork 607
Description
This unfortunate and hard to parse license reference is common and promoted by the GNU Gettext tool that generates templates for translations that yield eventually pretty weird things such as this:
https://github.com/sugarlabs/physics/blob/5e73470fc3c730c05f3bdcae830f630fd5ceb45c/po/mk.po
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
... and so repeated over and over.
Or this kind of hard to dereference statement:
# This file is distributed under the same license as the cpufrequtils package.
The culprit code is there:
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-tools/src/xgettext.c#n1907
@ueno @bhaible this is a source of less accurate license detection for scancode and a lot of noise and there are 100K+ examples of such license reference out there... I might be able to deal with it somehow. But may be there would be a way to fix it upstream in gettext proper to avoid propagating weak and inconclusive licensing statements in the future? that would be really nice!
@ian-kelling ping... has this been an issue when you scan code at the FSF too?