• Copyright for translations and templates

    From Marc Haber@21:1/5 to All on Wed Sep 13 12:40:01 2023
    [please Cc me on answers, I am not subscribed to debian-i18n]

    Hi,

    licensing of translations and templates are a pet peeve of mine. I think
    we often do not pay enough attention on this topic and I usually try to
    do better in this regard. When a translator submits a translation for
    one of my packages, I pay attention on a proper copyright notice in the translation that I can refer to in debian/copyright without blushing in
    shame.

    I must however admit, that my preparatory work is often not as good as I
    would like it to be. For example, some of adduser's manual page
    translations have grown a copyright statement that assigns copyright to
    the FSF without stating which license is to be applied. This cannot be
    correct, and strictly speaking those translations need to be thrown out
    and started over again with a proper license by a known translator.

    In the past I was able to ignore this, but in the days of DEP-5 forced attention to copyright and licenses I cannot overlook that any more.

    What is the recommended way to handle this?

    - throw all improperly licensed translations out and start over?
    - ask a translator who submits a new translation to fix the copyright
    statemennt, moving the burden of work from the package maintainer to
    the translator? I have already had translators saying like "no, that's
    not my job" to that request
    - continue ignoring the subject?

    And if that's not interesting enough, we strictly have two copyrights
    applying to translation files: Once the author of the code/document
    being translated, as the English version of the text is also in the po
    file, and second the translator who has clearly authored the
    translation.

    Is it clearly documented how to handle this?

    Greetings
    Marc

    -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Kreutzmann@21:1/5 to Marc Haber on Wed Sep 13 21:10:01 2023
    This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages.

    Hello Marc,
    (yes, I'm aware of the background)
    On Wed, Sep 13, 2023 at 12:36:59PM +0200, Marc Haber wrote:
    licensing of translations and templates are a pet peeve of mine. I think
    we often do not pay enough attention on this topic and I usually try to
    do better in this regard. When a translator submits a translation for
    one of my packages, I pay attention on a proper copyright notice in the translation that I can refer to in debian/copyright without blushing in shame.

    I'm doing quite a few L10N NMUs and I know that quit a few
    debian/copyright ignore translations all together (unfortunately),
    which I usually fix.

    I must however admit, that my preparatory work is often not as good as I would like it to be. For example, some of adduser's manual page
    translations have grown a copyright statement that assigns copyright to
    the FSF without stating which license is to be applied. This cannot be correct, and strictly speaking those translations need to be thrown out
    and started over again with a proper license by a known translator.

    Why? You usually got the name. This is IMHO sufficient. The template
    has some license, often "the same as upstream". Even if not copied
    over, I think it is sensible to assume that this choice was carried
    over - otherwise the translator could have denoted so[1]. And many
    interfaces for translator do not stress license issues, so many
    translators might not even aware of this problem. And for sure,
    translations *only* work with the original software, putting a
    proprietory license (in therory) on them, makes absolutely no sense.
    So I think my reasoning is valid.

    And for copyright: Stating "(C) My name" is nice, but not a
    prerequisite. It just eases reasoning for later claims (e.g.
    originality) which are less relevant for translations.

    - throw all improperly licensed translations out and start over?

    This would be a large pitty. And I think you should only do this if
    advised so by debian-legal. In a related case (#555168) it was not
    necessary at all, but again, the situation was slightly different
    there, but also (improper, copy past, wrong) statements did not force exclusion.

    - ask a translator who submits a new translation to fix the copyright
    statemennt, moving the burden of work from the package maintainer to
    the translator? I have already had translators saying like "no, that's
    not my job" to that request

    You can kindly ask, but as stated above, probably you first (and
    again and again) need to explain this - and this person might not know
    it either. For their translation, yes, but often they do not know the
    previous translators either. So they are in the same situation as you,
    having a name and maybe an e-mail address, which often does not work
    anymore. So do not expect much, except that of course translators
    should clarify their own work (i.e. in the header).

    - continue ignoring the subject?

    No. What I always do is to simply assume the copyright is as the
    template, but tools destroyed it[2], deleted it etc. So the translator
    kept the license. I update debian/copyright accordingly and possibly
    the po file as well (but be careful, chosing an editor which can
    handle the charset).

    This is IMHO the only way to handle the muddy past.

    And if that's not interesting enough, we strictly have two copyrights applying to translation files: Once the author of the code/document
    being translated, as the English version of the text is also in the po
    file, and second the translator who has clearly authored the
    translation.

    For me (but I'm not a lawyer) a translation is a derived work. So the
    license of the translation has to be part of the license of the
    original work. And the copyright is joint, i.e. the authore of the
    original strings and the translators. So for my view - nothing special
    to see here.

    Is it clearly documented how to handle this?

    This I don't know. At least several packages ignore this and I've seen
    many debian/copyright *without* the copyright notice of the
    translators, which is a pitty.

    Greetings

    Helge

    [1] This is a fundamental question. If I copy over free code, modify
    it and and remove the license, and then republish it. You can
    state that I can only legally do this under a free license, so
    assume that the license carries over. Or you can state that "if in
    doubt, all rights reserved" and start suing all users of this
    modified code.

    [2] I did see cases with strange statements, e.g. in
    package A a translation stating "same as B". Then I need to
    clarify this, unless license A == license B.

    --
    Dr. Helge Kreutzmann debian@helgefjell.de
    Dipl.-Phys. http://www.helgefjell.de/debian.php
    64bit GNU powered gpg signed mail preferred
    Help keep free software "libre": http://www.ffii.de/

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEbZZfteMW0gNUynuwQbqlJmgq5nAFAmUCBjsACgkQQbqlJmgq 5nA+zhAAkKJRq3HlDOqvYKCykUF9DllTmNBh6zL3VZm5UklzvsVjJivHQr5uYgMQ EUiFyhnh8u5Tv7sf4UYAWNDcSl2QfdIj3516TWtPrMTEceSWJEfdaYrpyvxIU4ob OgoWNriWy/tqf+WwY66CIBTH/MFfizr8ZNnUuCY7dpux+XHkQ9+r91slWWWBuEhn BRhboAyIlicBkUo3ApduSCLEicQUX7TjXxoS/9m8HIIhcXtXQX6tUjo/rk23YhSZ 8Rv93DHGgAX0pvR40WAe1ihd5iG5nn+Ybb2z2ObBtOtLe+wvsqypATuzaEbg6rKh ok1JZEEcAN/2FJ0GG1mVYsLDx38ScjvlsD9rE+ecmOIHKwQF6WmMMsc3O7sasKIM Gf+VCqLG3BcOqzYEol9NQLdzFDV/+ceJr/54C3Cg4U38i4eIJZA4k1j7ZL12okZT jiHJKar5TdHeiTR24QprOnIaD3RlTVU5K31xFEReoiI8aMOD21/bkjjiuvIR9BtU LXxIneIso2GJenQwz1XzaBe/0OckmkKfEmCyUE8F9QtOGGSGgFo8BWSFqO79bqWi B/iIGEZ6web3cF6utwvj0uzYYtLYEqzOLz+5uUQ