After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 438348 - License problems in po files
License problems in po files
Status: RESOLVED OBSOLETE
Product: l10n
Classification: Infrastructure
Component: other
git master
Other Linux
: Normal normal
: ---
Assigned To: GNOME i18n team
Christian Rose
Depends on: 553151 553152 553153 553154
Blocks:
 
 
Reported: 2007-05-14 15:34 UTC by Xan Lopez
Modified: 2014-08-31 12:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Comment 1 Behdad Esfahbod 2007-08-08 22:28:42 UTC
Lets see if localization coordinators can handle this.
Comment 2 Behdad Esfahbod 2007-08-08 22:29:03 UTC
Humm, l10n can use a general component...
Comment 3 Claude Paroz 2007-08-25 09:26:32 UTC
Reaffecting to "other" component
Comment 4 Claude Paroz 2007-08-25 09:30:57 UTC
Here is the standard header used in French GNOME translation team:

# Copyright (C) 2003-2007 Free Software Foundation, Inc.
# This file is distributed under the same license as the @PACKAGE@ package.

@PACKAGE@ being replaced by current package name. This has the advantage of not redefining the license (keeping translations GPL with GPL modules, LGPL with LGPL modules, and so on).
Comment 5 Leonardo Ferreira Fontenelle 2007-08-26 15:22:56 UTC
Let me see if I understood it correctly. Should we (translators) leave a literal @PACKAGE@? Currently in the pt_BR l10n team we use these lines but write something like "... the ATK package."
Comment 6 Claude Paroz 2007-08-26 18:21:52 UTC
No, you should replace @PACKAGE@ by the real package name. Your current practice is entirely correct.
Comment 7 Duarte "HappyGuy" Loreto 2007-08-26 23:56:05 UTC
Hello

I've been using for several years now the following header

# Copyright © 2006, 2007 pessulus
# This file is distributed under the same license as the pessulus package.

Differs from the above one given by Claude where it assigns copyright to the package and not to FSF.

I believe this is the correct way to do it as we grant to the package maintainers the possibility to relicense the package without requesting our permission or, if we become unreachable on the specified email, forcing maintainer to discar the translation.

On the other hand, I think that granting translation copyright to FSF is invalid unless the translator has an agreement with FSF. As such, seems that the only valid alternative to granting copyright to the package is to keep it for the translator himself.

I think all this header discussion was conducted on the list some 5 years ago but I'm not sure and not able to find it on the archives/google.

On a side note, I always convert the (c) to © as .po files are should support UTF-8 and it's a more correct glyph to put on the header.

Am I wrong on the way I do the headers? Should we get some legal folks opinion here?
Comment 8 Vincent Untz 2007-08-27 06:07:06 UTC
You cannot grant copyright to someone else if you don't sign any paper. That's all. There has been some discussion about copyright on foundation-list in the last few weeks, so you can read the thread, even if it's not about translations.
Comment 9 Christian Rose 2008-09-21 16:19:48 UTC
(In reply to comment #3)
> Reaffecting to "other" component

I've split this up into separate bug reports:

  mr: bug #553151
  tk: bug #553152
  hr: bug #553153
  vi: bug #553154

Perhaps this will help the issue get attention by the respective translation teams.
Comment 10 Chris Leonard 2012-03-27 03:43:04 UTC
As all of the component bugs but one are fixed, can this ticket be closed?
Comment 11 Leonardo Ferreira Fontenelle 2012-03-27 09:43:51 UTC
(In reply to comment #10)
> As all of the component bugs but one are fixed, can this ticket be closed?

The TK bug report is open (since 2008).
Comment 12 Chris Leonard 2012-03-28 03:20:06 UTC
That is exactly what I meant by "all but one".  As that TK is open as it's own ticket in bug #553152, does keeping this bug open continue to serve any purpose?

At this point in time, isn't this effectively a duplicate of #553152 ?
Comment 13 André Klapper 2014-08-31 12:43:16 UTC
Closing as per comment 12 (which is correct).