Hungarian localization -- questions about legal issues

[Gergely Kis]

Hi,

A group of Android enthusiasts is planning to create the Hungarian
localization for Android and contribute it to AOSP.

We are organizing on the Hundroid list:
http://groups.google.com/group/android-hu

We would like to use an online translation tool like Launchpad or
Pootle to do the translation.

There are a few technical / administrative questions:
1. Regarding the CLAs: In such online tools people's contributions
tend to end up in different parts of the system. Should everyone
involved have a CLA on file?
2. Even if everyone has a CLA on file, it is just not possible to send
in the individual contributions separately. Is it OK to just send the
contribution as a single changeset?
3. Launchpad requires to license the translations under BSD license.
Is it ok to "relicense" these translations to Apache 2.0 when sending
in the contribution?

Best Regards,
Gergely

[Jean-Baptiste Queru]

I unfortunately don't have a definitive answer about the CLA aspect,
or on the BSD/ASL2 aspect.

Besides the legal aspect, the big problem is that AOSP isn't currently
in a position to accept localizations. Long story short, the
translated resource files that you see in the Android source tree
aren't the actual source files, the real sources are on Google's
internal translation servers and the process to export them from there
into the Android source code is destructive for whatever translations
exist in the Android source tree.

So, really, the first thing that you need to resolve is to modify the
existing resource-processing tools to be able to gather the resources
for individual translations from separate git projects.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Gergely Kis]

Hi,

Just to get this straight:

I saw some contributions in Gerrit (e.g. Ukrainian), and I vaguely
recall that they might have been accepted into into AOSP. You are
saying that these will be overwritten if an "official" translation is
going to be released?
And therefore you no longer accept such contributions into the tree?

You are also saying that our work has basically no chance of getting
included in the official tree for example for Eclair?

This is important because our group mostly uses AOSP or other
unofficial firmwares, but the main goal would be to make sure that
Hungarian is supported in regular consumer devices as well.
Based on your email am I correct to assume that this can only happen
if someone contracts Google to add support for this locale?

The funny thing is that already 2 providers have Android phones on the
market in Hungary: T-Mobile and Vodafone. Yet, it seems that they did
not pay for the support of the proper hungarian locale, consequently
there is no Hungarian translation in Donut.

You mentioned that we should look into adding support for taking
translations from external git repositories into the build system.

If we go one step further: Do you think it would be possible to add a
runtime system which allows external applications to contribute
translations to other applications. This would be largely similar to
the IME framework, which allows the creation of localized input
methods. Or more importantly: do you think that such contribution
would make it into the official release if it gets into AOSP?

Regarding separate localization repositories: Since the localization
data is not too big, I think it would make sense to put it into a
single repository / locale (or even locale family like the different
german or spanish and portugal locales.) Do you agree? It would also
make the life of translators simpler: they only have to deal with a
single repository instead of a 100. :)

Thank you and Best Regards,
Gergely

[Jean-Baptiste Queru]

The case of the Ukrainian translation that was uploaded is what caused
us to think about that aspect of the project in greater detail and to
realize that we weren't currently equipped to deal with such a
translation.

There's indeed little chance that your work would end up in an
official release. However, if it's stored as a separate project, a
device manufacturer could decide to use your translation by just
including it that project in their source tree. If the primary
translations were also maintained in separate projects that way, it'd
allow OEMs to easily swap their translations in.

I do think that it'd be great to be able to be able to augment
resources of other apps at run-time, but that's quite a separate
issue. One of the keys here is probably to deal with the security
aspects, such that an external translation can only change resources
when the relevant language is selected, and probably such that it can
only modify strings (i.e. not layouts or drawables). Dianne, do you
have an opinion about this?

JBQ

[Dianne Hackborn]

One basic logistical to accepting external translations is maintaining them across releases.  For example, every release we have done so far has had last-minute string translations, not infrequently a week before the final build, which need to go through a localization pass for all languages.  We can make sure that all of the localization we are managing will track those changes, but it would be very difficult to do this with 10 different external localizations, and if they can't be complete for a platform release then I don't think they should be part of the platform.

Of course things may be different for a stable branch -- for example there is no longer any active development going on in Donut, so there won't be new strings, so I think it could be feasible for people to add localizations there.  They just wouldn't be carried over to the next mainline development branch.

Regarding:

I do think that it'd be great to be able to be able to augment
resources of other apps at run-time, but that's quite a separate
issue. One of the keys here is probably to deal with the security
aspects, such that an external translation can only change resources
when the relevant language is selected, and probably such that it can
only modify strings (i.e. not layouts or drawables). Dianne, do you
have an opinion about this?

Don't quote me on this, but hopefully next year we will have runtime resource overlays implemented for this and other situations.

--

Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Jean-Baptiste Queru]

We wouldn't be including the external translations in any of the
standard platform manifests (and most certainly not in the official
tagged releases). That'd be impossible to manage. We could host them
on the AOSP servers (assuming they are licensed appropriately), but
they'd be like the other hosted projects that aren't part of the
official manifest, very much "as is".

JBQ

[Jean-Baptiste Queru]

I'm not a lawyer, I never tried to become one, I don't even play one
on TV or on the Internet. This is not legal advice from me, from
Google, from the Android Open-Source Project, from the Open Handset
Alliance, from my wife, from my dog, or from anyone else. English
isn't even my native language. Take this with a very large grain of
salt and talk to a real lawyer if you want some real answers. Don't
tell me later that I didn't warn you ;-)

As I understand here, the key here is about the contributions being
properly authorized by the copyright owners, i.e. by default the
authors of the translations.

From that point of view, the answer to (1) is likely to be "yes".
Along the same lines, (2) is probably a "yes" as well, as long as
every author has a CLA on file and agrees to have their contribution
uploaded.

As for (3), I'm not familiar with the details of launchpad, but I
hope/assume that the authors of the translations done there retain the
copyright for their translations. If that's the case, and if every
author (i.e. every copyright owner) agrees to it, nothing prevents the
group of authors from making the same translations available through
launchpad under a BSD license and separately through AOSP under an
Apache 2.0 license (from that point, people who get the translations
through launchpad will have to follow the terms of the BSD license,
and people who get them through AOSP will have to follow the terms of
the Apache 2.0 license).

Once again, I'm not a lawyer, this is not legal advice, blah blah
blah, but I hope it helps a bit.

JBQ

On Tue, Oct 13, 2009 at 10:16 AM, Gergely Kis <gerge...@gmail.com> wrote:
>

[Gergely Kis]

Dear JBQ,

Thank you for the legal non-advice :)

You described pretty much, what I was thinking myself.

Is there a way to get an official statement from someone at AOSP? Or
we need to first make a submission so that you can open a ticket
internally or whatever process you need to follow?

I don't want to overcomplicate things, but we really would like to do
things in an AOSP compatible way.

We could just go and create the 2 git repositories somewhere else to
host the manifest and the translation files. "End users" would see no
difference, they would simply use our builds, and would not care about
the build manifest.

But we think that working this process out has value to AOSP and would
enable other small languages to have good support.

Basically we have discussed to methods in our group: (I just include
it here again for reference, if you want to forward it internally.)

1. Use a separate Pootle installation and require all contributors to
have a CLA on file. Then someone would create changesets from these
online translations and upload through Gerrit into the future
translation repository. I think this is straightforward from the
licensing perspective. We will use this approach if we cannot get a
clear statement on the other one.

2. The other method that came up is to use Launchpad.net for the
translations. The main benefit would be to get access to the
translation memory stored there, which could make the work faster.
However, Launchpad.net requires all translations be under the BSD
license, owned by the individual translators. As far as I know the BSD
license allows relicensing, as long as the original copyright and
license is kept intact. I am not sure how this is done properly.
But since I am not a lawyer, and don't want to be one, if there is no
quick way to solve this, we will just go with option 1.

For reference here are the licensing related links to Launchpad.net
https://help.launchpad.net/Translations/LicensingFAQ
https://help.launchpad.net/TermsofUse

If we go with Pootle and it works out well, we might open it up for
other teams too. If it is worth it, I could even try to integrate user
management with Gerrit to make sure that only people with a CLA on
file get access.

Thank you again and Best Regards,
Gergely

[Jean-Baptiste Queru]

I don't think that you'll get any kind of real legal advice from a
mailing list, and AOSP isn't a lawyers' firm. You'd really have to pay
your own lawyer for that.

As the copyright owner(s), the fact that you license your files as BSD
to one set of people doesn't prevent you from licensing the exact same
files to another set of people with any other license you wish. That's
the fundamental nature of copyright.

That being said, and especially given that we're looking at hosting
the translations as a separate git project, a BSD license wouldn't be
an issue anyway. If that makes your life easier (and it sounds like it
would if you used launchpad), let's do it that way. Let's not add
unnecessary complexity.

JBQ