There has been a vague plan to do this all along. 
It just needs a reasonable list of common licenses and a patch...

Just dropping ideas:

  - It the parser will ignore whitespace and lowercase the tag, and try to match against the list of available licenses.  They may look like 'GPL 2.0', 'GPL 2.1', 'GPL 2.1+', 'CC BY', things like that.

  - We can start by just GPL and LGPL and then later run a GNOME Goals session on cleaning up the about dialog in apps (it's in the wiki), and ask people to submit patches for their licenses that we don't support.

  - We may want to add a way to add exceptions to common licenses, without having to duplicate the translation again.  I'm not sure how to do this without adding new API.  Probably the parser should only parse and handle the first line of the license string.  So you can pass in a license string of "GPL2.1+\n\nAs an exception, you may to this and that...".

  - Support dual-licensing.

for dual-licensing, we might just say that people have to put in the full text,
since you likely want some text surrounding the licenses anyway, in that case.

It may also make sense to put all the license stuff in a separate pot-file or domain.

In fact it better go into a new property "license-name".

Ok, now that I'm down to patching, there's a little problem, that now the about dialog code should call gettext.  That's basically why I thought a separate property makes more sense.  So should I define a set_translation_domain too?

Oops.  Ignore my last comment.

Created attachment 62371 [details] [review]
initial patch

Ok, this is almost what I've been thinking.  I decided to not create a new translation domain, as at this point I don't think it's worth it.

The way I chose was to add a "license-name" property to GtkAboutDialog.  Then if the "license" property is set, that will be shown to the user.  Otherwise, if "license-name" is set, available licenses are searched to find the requested license and shown (after substituting the application name into them), finally if search fails, a simple string "%s is licensed under the %s license." is shown.

I also did some nasty tricks to keep the paragraphs of each license in one char * to reduce relocations, but make each paragraph translatable separately.  Not sure if the increased complexity is worth, although it's really a matter of two or three lines of code.

Hmm. 
If we decide to move the licenses to a separate translation domain, we
can just fix it to be gtk-2.0-license-texts or similar.

The price for using gettext in this way is that you have the full
text of each supported license in the .data section. And the price for 
making each paragraph a separate msgid is extra copying in _gtk_license_text_get_for_name.

I would be a bit happier if _gtk_license_text_get_for_name
could just do

  return gettext (name)

That way a) we only have the short keys in the .data section and
b) we don't do extra copies to reassemble the license from paragraphs.

Ok, makes sense, except that then we need English translations to have the licenses for English even, and worse, if a language doesn't translate them, we don't get the fallback English text.  If that's fine, the rest can be worked out, a separate domain, and handcrafted pot file works.

So, if you don't have a German translation for "GPL", you would get
"Dieses Programm steht unter der GPL Lizenz", ie instead of falling
back to the English text of the license, we fall back to a German text
citing the license by name". Not sure if that is better or worse.

You are right about the need for English translations.

Ok, what about deciding about the API for 2.10 and decide about the actualy license text implementation later?  For now it can simply show the short string.

(haven't read all the above discussion in detail, sorry)

Isn't it a bit more reasonable to load the licenses from files? Maybe mmapped...

There are not many files that gtk+ depends on at runtime..
Please do read the discussion.  Depending on gettext does solve most of the problem, but introduces a couple new ones.

Well, I now read all the comments in this bug and I don't see separate file mentioned... some of the things that imho should be considered:

 - the licences translations is somthing that affects many programs even not using gtk. We would probably want the same translation shared.
 - normal translators are probably not qualified to translate a license correctly: no offense intended, but license are legalese and the choice of each word must be considered in detail
 - keeping the licence text in the binary is not very nice and doesn't scale well for many licences

My idea is that we add a licence-file property and program would simply mark from translation the *filename* so that each translator could change "/usr/share/GPL" to "/usr/share/GPL.it" etc

The problem with the scheme you suggest is that it will not solve the problem at hand, since we don't have a common place for licenses installed.  Behnam had this idea of a small package distributing common licenses and all, but I guess we don't want to depend on another library/package either.  And having a license-file property is very fragile IMO.

Putting the licenses in a separate translation domain doesn't necessarily mean that gnome-i18n translators should translate them.  But another question now that you mention it, is that whether we want to use the GPL entirely or the 3-paragraph header only?

Again, if we agree on the public interface, we can sort out where to store licenses later.

Note thay with my scheme gtk would not depend on the new licenses package. The programs (e.g. gnome) would depend on it. And in the mean time they could still take advantage of a licence-file property since almost all of them already install the COPYING file.

Oh yeah?  Not any of the packages I know installs COPYING.  Distributions do.

Note that a "license-file" property would be useful even to a program that doesn't use a "stock" license, as it wouldn't need to have the full text of its license in its source and in its .data section.  A "license-file" property would help everybody putting a license into a GtkAboutDialog.

A "license-file" property isn't mutually exclusive with a "license-name" of course, but it does seem overkill to do both.  Why not just add the more generally useful "license-file" and have GTK+ pass the buck on providing actual licenses?

The main problem with "license-file" is taht no package Iknow of currently installs its license file, while on the other hand every distro does that in its own place and way.  And that doesn't help with translations either.

If you have a concrete proposal about how the "license-file" property should work, I like to know.

And very few programs are putting the license in the About dialog right now.  If I, as an application developer, decide to put a license in my About dialog, then I can install the license file if I need to.  It's certainly no more effort than putting the license text inline in my source code.

Sure, there is no package right now that installs common licenses.  But that's true no matter what API gets added to GTK+.

What I'm saying is that a "license-file" property is generally useful to a lot of people.  If I develop an application that's dual-licensed, I can't expect GTK+ (or whatever other package) to provide the full text of my dual-license arrangement.  But I could still use the "license-file" property if I install my license somewhere, and I think this is nicer than what I'd have to do with the "license" property.

It's much like GtkImage providing the "file" property along with the "image" property.  It saves you the effort of reading the file yourself in your application code.

Shaun, agreed.  But how does translation fit here?

Well, having a "license-file" property would open the door for packages to install licenses in some common location, along with translations of those licenses.  Then translators could translate the file name.

Although that's going to present all sorts of problems:

1) Translators will end up translating the file name when they (or other translators) haven't translated the license in the appropriate package yet.
2) We won't be able to do _(DATADIR"/licences/GPL") because intltool won't be able to extract the string.  And we can't do _("/usr/share/licenses/GPL") either.  And even if we could do the first, app developers shouldn't necessarily use their own DATADIR.
3) We'll have issues of new license package versions not be installed in places where applications have translated file names.  Application developers are not going to watch which languages have translated the file name and update their dependancies accordingly for each release.

I'm just throwing ideas out here, but maybe GTK+ could do its own sort of multi-views content-negotiation-esque lookups.  So my application could request the license file "/usr/share/licenses/GPL", and if a user is running in German, GtkAboutDialog could look for "/usr/share/licenses/GPL.de" automatically.

With your last paragraph, I say you are back to license-name again.

Ok, lets do it like icons and docs are done.  You set a license-name like I propose above, and it is looked up in XDG_DATA_DIRS/gtk+/license/.  Gtk+ automatically falls back to English, like Yelp does for docs.  Gtk+ also ships with a default set of licenses, like gpl2, etc.  Apps shipping their own license can put the file in DATADIR/license/$appname (or create a symlink there) and pass $appname to about dialog.

Chpe also suggested opening the license in Yelp and let it handle translation lookup.  Not sure how feasible that is.

Asking translators to translate a file name is in my opinion way too error prone; most would not realize that it's afile name, or if they do what it's used for and how to translate it, and some few would probably be too optimistic and enter a different file name even though there is no translated file, causing weird runtime behavior when the file is to be looked up. Some others might ask the rightful question of "why do I have to translate this anyway, doesn't the software know if there is a translation present or not" etc.

I see this problem as two-fold:


1) Translation of license notices (as pointed out by Alexander Shopov in a recent thread on the gnome-i18n list):

"%s is free software; you can...\n"
"%s is distributed in the hope that it will be useful..."

and so on (where %s is the name of the application). This license notice blurb is extremely common and appears in handcrafted versions in many handcrafted about boxes already, and is driving translator nuts, both because they have to translate it over and over, and because slight changes in style and errors and typos in the text makes it not possible to reuse their translations.

But, and this is key; these notices are short. It should be possible to have some of these in GTK+, make it possible for application authors to optionally specify one of these with something like license = GPL_V2_OR_LATER; display_license_notice = true; and for gtk+ to use gettext() for the translations of these common notices.

For the GPL case, I think the recommendation from the FSF is to always include the English version, just in case, and make sure that the translated version says that its unofficial and that the English version is the normative one. So what you would actually mark for translation would be something like:

_("The following piece of text is an unofficial translation, which is provided for informational purposes only. The original English version which is provided below is to be used for all legal interpretations.\n\n%s is free software; you can redistribute it under..."), and so on, and then display the original license  notice below in English, without a gettext call.


2) Full license texts. Not many languages have translated versions of licenses like the GPL, and none of them are official. Also, the full license texts are lengthy. For these I do not see a problem with a file-based approach; gtk+ can include files with common licenses, and files with their unofficial translations, and do the lookup with a fallback to the English file, when the license property is set as described above.


So how about less common licenses? I think the only option here is to allow a license_file property which points to the application's license file, and make this property be mutually exclusive with the license property: you can use one or the other, but not both.
For translations, these are to be provided by the application, but the API should probably allow for some lookup; i.e. if we run in the "de" locale and the specified license file is "ourlicense.txt", then we use "ourlicense.de.txt" if it exists.

I would like to comment on the following:

1. Translation of licence notices (This is necessary):
I would even go as far as remove the %s parameter in the notices entirely. 
Thus these:
For example, these 
------------------------------------
Sound Juicer is free software; you can
Sound Juicer is distributed in the hope that it will be useful
GNU General Public License along with Sound Juicer

will become:
------------------------------------
This program is free software; you can
This program is distributed in the hope that it will be useful
GNU General Public License along with this program

I propose *no* %s parameters containing the name of the program - there are
languages that have genders, cases which will make the translations different
from program to program.

Use the generic "This program". We have the context, we know what "this" points
to.

The GPL v.2 advises the same: http://www.gnu.org/copyleft/gpl.html#TOC4

It will be easier for translators, strings will not get fuzzy when 
program names change etc., etc.

2. Translation of Licenses themselves - I am strictly against it. The official
versions are those that matter. Translations are no convenience whatsoever.
Epecially bad translations. There are far too many licenses out there! We
cannot provide translations to all of them.
We have to do some damage control here people!. For example - one of the
Bulgarian translation of the GPL v.2 the funny description of the program
"makes passes at compilers" became: "that makes holes in government sites"
http://bulgaria.sourceforge.net/prava/gplbg.html What you will get me with
License transations as a team leader is not a solution but another uphill
battle.

3. Get the low hanging fruit first. Do not think of a grand solution to life,
universe and everything else. My itch would have been scratched with a simple
policy to always use the same English originals and eradicate the small
differences. No need for API or GTK+ change.
Everyone is free to think their own different and incompatible license.
Everyone is free to make a double/triple/quadriple, etc. funny licensing scheme
depending on their mood or mixed up Moon-Venus caledendar. No need to think of
solution to this problem as it would backfire on us.

(In reply to comment #28)

> It will be easier for translators, strings will not get fuzzy when 
> program names change etc., etc.

That will not happen with "%s" either.

 
> 2. Translation of Licenses themselves - I am strictly against it. The official
> versions are those that matter. Translations are no convenience whatsoever.
> Epecially bad translations. There are far too many licenses out there! We
> cannot provide translations to all of them.

So?!  Some of us have quality translation of the major (say, GPL) licenses in our language, and we want to use it, because not all Persian speakers know English.


> We have to do some damage control here people!. For example - one of the
> Bulgarian translation of the GPL v.2 the funny description of the program
> "makes passes at compilers" became: "that makes holes in government sites"
> http://bulgaria.sourceforge.net/prava/gplbg.html What you will get me with
> License transations as a team leader is not a solution but another uphill
> battle.

So, fix the Bulgarian translation or reject it.  That's what you, the coordinator, are supposed to do.
 

> 3. Get the low hanging fruit first. Do not think of a grand solution to life,
> universe and everything else. My itch would have been scratched with a simple
> policy to always use the same English originals and eradicate the small
> differences. No need for API or GTK+ change.
> Everyone is free to think their own different and incompatible license.
> Everyone is free to make a double/triple/quadriple, etc. funny licensing scheme
> depending on their mood or mixed up Moon-Venus caledendar. No need to think of
> solution to this problem as it would backfire on us.

If you think we are doing unnecessary work and no Gtk+ API is needed, I don't understand why you're commenting here in the first place.

(In reply to comment #27)
> Asking translators to translate a file name is in my opinion way too error
> prone; most would not realize that it's afile name, or if they do what it's
> used for and how to translate it, and some few would probably be too optimistic
> and enter a different file name even though there is no translated file,
> causing weird runtime behavior when the file is to be looked up. Some others
> might ask the rightful question of "why do I have to translate this anyway,
> doesn't the software know if there is a translation present or not" etc.

Agreed.


> I see this problem as two-fold:
> 
> 
> 1) Translation of license notices (as pointed out by Alexander Shopov in a
> recent thread on the gnome-i18n list):
> 
> "%s is free software; you can...\n"
> "%s is distributed in the hope that it will be useful..."
> 
> and so on (where %s is the name of the application). This license notice blurb
> is extremely common and appears in handcrafted versions in many handcrafted
> about boxes already, and is driving translator nuts, both because they have to
> translate it over and over, and because slight changes in style and errors and
> typos in the text makes it not possible to reuse their translations.
> 
> But, and this is key; these notices are short. It should be possible to have
> some of these in GTK+, make it possible for application authors to optionally
> specify one of these with something like license = GPL_V2_OR_LATER;
> display_license_notice = true; and for gtk+ to use gettext() for the
> translations of these common notices.

This is in fact what my initial patch does, but mclasen prefers not to have even the short notices in the gtk+ binary, and that makes sense.


> For the GPL case, I think the recommendation from the FSF is to always include
> the English version, just in case, and make sure that the translated version
> says that its unofficial and that the English version is the normative one. So
> what you would actually mark for translation would be something like:
> 
> _("The following piece of text is an unofficial translation, which is provided
> for informational purposes only. The original English version which is provided
> below is to be used for all legal interpretations.\n\n%s is free software; you
> can redistribute it under..."), and so on, and then display the original
> license  notice below in English, without a gettext call.

Such a notice can be added by Gtk+ unconditionally.


> 2) Full license texts. Not many languages have translated versions of licenses
> like the GPL, and none of them are official. Also, the full license texts are
> lengthy. For these I do not see a problem with a file-based approach; gtk+ can
> include files with common licenses, and files with their unofficial
> translations, and do the lookup with a fallback to the English file, when the
> license property is set as described above.
> 
> 
> So how about less common licenses? I think the only option here is to allow a
> license_file property which points to the application's license file, and make
> this property be mutually exclusive with the license property: you can use one
> or the other, but not both.
> For translations, these are to be provided by the application, but the API
> should probably allow for some lookup; i.e. if we run in the "de" locale and
> the specified license file is "ourlicense.txt", then we use "ourlicense.de.txt"
> if it exists.

Yeah, file name lookup makes sense.  This is just like what yelp does for example.

Hi, is there some work in progress about this ? I would like to launch this GNOME Goal:
http://live.gnome.org/GnomeGoals/AboutDialog

I for now update the guidelines to include the full text of the license, as there's no patch commited.

I suggest holding that on.  Or go on with the GnomeGoal but don't provide full license text.  That's a huge waste of translator resources and we know that we will fix this issue someday in not so distant future...

To make progress we need someone like mclasen to wrap up the discussion/

Well, for me the copy/pasted license text should remain untranslated for now. But translated licenses in GtkAboutDialog will sure be a nice feature when this API will be finished.

ok, I find it a bit hard to distill an actual api proposal out of this discussion,
but I think there are two proposals here:

1) a license-name property, that would take values like "GPL", "GPLv2", "LGPL", 
 that would allow us to do smart things like looking for translations somewhere on the disk, or just put a translated boilerplate like "This program is under the FOO license", if the license text is not found on disk.

2) a license-file property that provides an escape hatch for custom licenses that you don't want to put into a string literal

So one research item for somebody here is to investigate what prior art there is in distros wrt to shipping licenses and translations in a central place.

ISTR Debian is already doing this. Where are they installing the licenses ?
How are the translations named ?

Behnam, can you answer Matthias's question in comment #35?

(In reply to comment #35)
> ISTR Debian is already doing this. Where are they installing the licenses ?

Not really.  Debian is shipping some of the most popular licenses in the package "base-files"; they reside in /usr/share/common-licenses/.  Currently included are GPL, LGPL, FDL, the Modified BSD license and the Artistic license.  Each package which is under one of this licenses just includes a short copyright notice in debian/copyright (that's /usr/share/doc/<package>/copyright when installed) that points to the full text of the license.

TTBOMK, no decision was taken regarding translations; I can't recall any recent discussions either.  Translations (of FSF licenses, at least) are always unofficial so I doubt that any action will be taken towards this idea.  It's too much work for little benefit.

So how are those exactly named?  A "find /usr/share/common-licenses" helps.

Sorry for not being clear.

yavor@patilan:~$ ls -l /usr/share/common-licenses/
общо 108
-rw-r--r-- 1 root root  6111 1996-12-16 04:58 Artistic
-rw-r--r-- 1 root root  1499 1999-08-26 15:06 BSD
lrwxrwxrwx 1 root root     8 2007-04-25 14:55 GFDL -> GFDL-1.2
-rw-r--r-- 1 root root 20403 2006-10-06 01:00 GFDL-1.2
lrwxrwxrwx 1 root root     5 2007-04-25 14:55 GPL -> GPL-2
-rw-r--r-- 1 root root 17987 2006-06-15 23:01 GPL-2
lrwxrwxrwx 1 root root     8 2007-04-25 14:55 LGPL -> LGPL-2.1
-rw-r--r-- 1 root root 25284 2006-04-28 00:32 LGPL-2
-rw-r--r-- 1 root root 26527 2005-06-16 17:32 LGPL-2.1

As you see, the generic abbreviations of the FSF licenses are symlinks to the latest version.  So if a package is "GPLv2 only", the link in debian/copyright points to /usr/share/common-licenses/GPL-2.  If it is "GPLv2 or later" it points to GPL, which will automatically point to GPL-3 once it's released (and the "base-files" package updated, of course).

Those are plain text files in US-ASCII.

P.S.  I'm not a Debian developer.

gnome-desktop also provides GNU licenses (with translations, in DocBook format):
  /usr/share/gnome/help/gpl
  /usr/share/gnome/help/lgpl
  /usr/share/gnome/help/fdl

See http://svn.gnome.org/viewcvs/gnome-desktop/trunk/desktop-docs/ as well.

(Yeah, I know gnome-desktop is supposed to go away at some point, and Gtk+ won't depend on it, but I'm just saying... :)

Hmm, I don't think we are prepared to include a docbook parser in gtk...

Hi, is there something we can do to move things forward ? Could GTK+ ship some plain text files with the usual licences ? Or do we need a special library for this (sounds bad idea) ? Or should we just display the content of the COPYING file for the moment and forget about this ?

*** Bug 471701 has been marked as a duplicate of this bug. ***

Please, don't forget this issue!! I think is a good idea!!

*** Bug 501074 has been marked as a duplicate of this bug. ***

What's the status on this?

Actually a year has passed and still is assigned ... assigned to what? :-/

Any follow up or discussion about it?

Lacking any sign of consensus on the design, I gave it up.  Anyone should feel free to pick it up again.

Maybe useful see how KDE solves the problem: http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKAboutData.html

> So?!  Some of us have quality translation of the major (say, GPL) licenses in
> our language, and we want to use it, because not all Persian speakers know
> English.

If it wasn't done by a lawyer it isn't a quality translation, FWIW.

> If it wasn't done by a lawyer it isn't a quality translation, FWIW.

Never mind.  I was young and foolish... :)

Also, looking at the patch, I'd suggest using simplified text (as suggested by GPL2) rather than the full code header.

The license says:

"If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”."

In the modern context, 'show w' and 'show c' might be links to the FSF's website (and the handful of official translations they have) rather than to local copies of the translated license.

I've worked on a patch that implements what Luis suggests in comment 52.

Created attachment 165692 [details] [review]
about: Add :license-type property

The :license-type property of GtkAboutDialog allows using a symbolic
enumeration value that will construct a placeholder license preamble
linking to a specific URL. This allows localization of the licensing
text without using a translation of the actual license, since it would
not be valid.

Maybe typo?
-+      license_preamble = g_strdup_printf (gtk_license_preamble, url);
++      license_preamble = g_strdup_printf (_(gtk_license_preamble), url);

(In reply to comment #55)
> Maybe typo?
> -+      license_preamble = g_strdup_printf (gtk_license_preamble, url);
> ++      license_preamble = g_strdup_printf (_(gtk_license_preamble), url);

yep, simply forgot the _().

Created attachment 165715 [details] [review]
about: Add :license-type property

The :license-type property of GtkAboutDialog allows using a symbolic
enumeration value that will construct a placeholder license preamble
linking to a specific URL. This allows localization of the licensing
text without using a translation of the actual license, since it would
not be valid.

Review of attachment 165715 [details] [review]:

Looks good to me in general.

::: gtk/gtkaboutdialog.c
@@ +401,3 @@
+   * specified in the #GtkAboutDialog:website property.
+   *
+   * Setting this property overrides the #GtkAboutDialog:license property.

For properties which have a side-effect like this, I prefer to have a clearly discernible 'unset' state. Either make GTK_LICENSE_UNKNOWN not override the license-text, or add an UNSET state

@@ +2544,3 @@
+      g_string_append (str, priv->copyright);
+      g_string_append (str, "\n");
+      g_string_append_printf (str, _(gtk_license_preamble), url);

I think an explicit gettext call would be slightly clearer here.

(In reply to comment #58)
> Review of attachment 165715 [details] [review]:
> 
> Looks good to me in general.
> 
> ::: gtk/gtkaboutdialog.c
> @@ +401,3 @@
> +   * specified in the #GtkAboutDialog:website property.
> +   *
> +   * Setting this property overrides the #GtkAboutDialog:license property.
> 
> For properties which have a side-effect like this, I prefer to have a clearly
> discernible 'unset' state. Either make GTK_LICENSE_UNKNOWN not override the
> license-text, or add an UNSET state

sounds good. GTK_LICENSE_CUSTOM might be more expressive; if you set the :license property, :license-type is set to 'custom', and if you set :license-type to 'custom' then you're supposed to be setting the :license text yourself.

> @@ +2544,3 @@
> +      g_string_append (str, priv->copyright);
> +      g_string_append (str, "\n");
> +      g_string_append_printf (str, _(gtk_license_preamble), url);
> 
> I think an explicit gettext call would be slightly clearer here.

okay.

Created attachment 165737 [details] [review]
about: Add :license-type property

The :license-type property of GtkAboutDialog allows using a symbolic
enumeration value that will construct a placeholder license preamble
linking to a specific URL. This allows localization of the licensing
text without using a translation of the actual license, since it would
not be valid.

I still prefer a string license identifier instead of an enum...

Any strong reason to hold this up over enum vs string ?

Referring to the licenses using strings leaves open the possibility to add new API to register custom system-wide licenses in the future (if desired, that is) without any API/ABI breaks, I think.

extending an enumeration is not an API/ABI break. and if you need a custom license you can still use the :license property instead of the :license-type.

using string identifiers makes the code a little bit more awkward to implement, and to use.

lets go with the patch as is. Committed to master

(In reply to comment #58)

> @@ +2544,3 @@
> +      g_string_append (str, priv->copyright);
> +      g_string_append (str, "\n");
> +      g_string_append_printf (str, _(gtk_license_preamble), url);

Is this assuming that copyright ends with a '\n' already? Because otherwise the copyright and the license preamble are in the same paragraph. Appending a double '\n' instead would make it look nicer.