bugGNU gettext - Bugs: bug #55733, The scancode program does not grok...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #55733: The scancode program does not grok "This file is distributed under the same license as ..."

Submitter:  Bruno Haible <haible>
Submitted:  Sun 17 Feb 2019 11:57:42 PM UTC
   
 
Category:  Programmer tools Severity:  3 - Normal
Item Group:  None Status:  Not a Bug
Privacy:  Public Assigned to:  haible
Open/Closed:  Closed

Mon 18 Feb 2019 12:31:18 PM UTC, comment #3: 


> Out of its original context, I would need to know what is cpufrequtils, where to find it.


Why are PO files occurring outside of the context of their package? What are you doing with them?

> Another example of these references (not in Gettext) are short notices such as: "See COPYING for license". This is nice and short and completely useless if the COPYING file is not copied over with every copy of the file that has such notice.


Yes, if someone copies some sources that reference a COPYING file, while omitting that COPYING file, you can't do much with the result. But that is a problem of the person or process which omitted the COPYING file, not a problem of the package author who create the package that included the COPYING file.

When it comes to a court procedure, the lawyers inquire about the intent. When a license notice says "See COPYING for license" the intent is clear enough, and unless the package contains multiple different COPYING files, it is also unambiguous.

Bruno Haible <haible>
Group administrator
Mon 18 Feb 2019 11:08:08 AM UTC, comment #2: 

Bruno:
Thank you very much for taking the time to create this ticket. I should have done it first.

You wrote:

> License notices are primarily meant for humans, including lawyers. A statement like "This file is distributed under the same license as the cpufrequtils package." is perfectly clear and unambiguous to humans, including lawyers.


It is indeed, as long as the file is seen in the package. Out of its original context, I would need to know what is cpufrequtils, where to find it. And there could be more than one package named cpufrequtils and it could have chaged its version over time. All of these are sources of ambiguities.

 

> A PO file MUST have a license notice, otherwise it cannot be distributed and installed with the package.


I am not sure this is a MUST as you say. The license exists irrespective of a per-file statement AFAIK. But irrespective of this, if you have a notice it is better IMHO than it be non-ambiguous. Another example of these references (not in Gettext) are short notices such as: "See COPYING for license". This is noce and short and completely useless if the COPYING file is not copied over with every copy of the file that has such notice.



> The only other option would be to copy the license's text to the PO file, and this would mean additional trouble:


A short notice is fine, just that it would be best if it could stand on its own?

> 2. Translators would need to learn about licenses, differences between GPLv2 and GPLv2+ and so on.


If they are contributing translations under a certain license, they better learn and know what license they contribute under.

> 3. Trouble when the package changes its license.


I am not sure why: if the license is clearly stated, then if the package change its license, it would update and change its notices.

Otherwise you can end up with this scenario:
Package XXX v1 is GPL-licensed. I contribute a translation "under the same license as the XXX package"
Package XXX v2 changes to a proprietary license. Someone stumbles on my translation and wrongly assumes this is proprietary.
Here none had bad intentions. Just that the weak "same license as XXX" notice creates ambiguities.

> This sentence "This file is distributed under the same license as ..." is fulfilling its goal: it has not caused trouble between developers and translators in the last ca. 20 years.


Maybe none cared before? ;)

> The text "# This file is distributed under the same license as the PACKAGE package." is template text. When you encounter it, it indicates incomplete adaptation of the package for use with gettext. Please point the developers to this section of the gettext manual: https://www.gnu.org/software/gettext/manual/html_node/po_002fMakevars.html


When taken outside of the original package context, I would now need to "de-reference" that package name reference, whether I am a human or a program. There are over 100K+ instances of the verbatim: "This file is distributed under the same license as the PACKAGE package"
See:
https://www.google.com/search?q="This+file+is+distributed+under+the+same+license+as+the+PACKAGE+package"
https://github.com/search?p=4&q=%22This+file+is+distributed+under+the+same+license+as+the+PACKAGE+package%22&type=Code

>> I might be able to deal with it somehow.
> So, please deal with it somehow.


I cannot cure these 100k+ issues and make all these translators and developers learn about the proper use of variables in gettext... That would be huge and formidable work to contact possible thousands of people. And I cannot easily dereference with code short of building a massive index of every package name reference, dates and so on which would be huge. The only thing I can do is propagate the ambiguity by detecting such a notice and reporting it as something that is ambiguous and requires extra review.

Which is why I had reached out to see if this could be mitigated here for the future.

Philippe Ombredanne <pombredanne>
Mon 18 Feb 2019 12:02:07 AM UTC, comment #1: 

License notices are primarily meant for humans, including lawyers. A statement like "This file is distributed under the same license as the cpufrequtils package." is perfectly clear and unambiguous to humans, including lawyers.

A PO file MUST have a license notice, otherwise it cannot be distributed and installed with the package. The only other option would be to copy the license's text to the PO file, and this would mean additional trouble:

1. More work for the developers who gettextize their package.
2. Translators would need to learn about licenses, differences between GPLv2 and GPLv2+ and so on.
3. Trouble when the package changes its license.

This sentence "This file is distributed under the same license as ..." is fulfilling its goal: it has not caused trouble between developers and translators in the last ca. 20 years.

> I might be able to deal with it somehow.

So, please deal with it somehow.

The text "# This file is distributed under the same license as the PACKAGE package." is template text. When you encounter it, it indicates incomplete adaptation of the package for use with gettext. Please point the developers to this section of the gettext manual: https://www.gnu.org/software/gettext/manual/html_node/po_002fMakevars.html

Bruno Haible <haible>
Group administrator
Sun 17 Feb 2019 11:57:42 PM UTC, original submission:  

Reported in https://github.com/nexB/scancode-toolkit/issues/1379 :

this kind of hard to dereference [statement](https://git.zx2c4.com/linux/plain/tools/power/cpupower/po/de.po):
`# 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!

Bruno Haible <haible>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pombredanne (Posted a comment)
  • -email is unavailable- added by haible (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-18 haible StatusNone Not a Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code