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

[Philippe Ombredanne]

Follow-up Comment #2, bug #55733 (project gettext):

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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55733>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/