Hi Peter, У уто, 23. 09 2008. у 22:44 +0100, Peter Clifton пише: > We want(ed) to use launchpad as a non-technical way to have people > translate our suite of GPL applications, but we also keep translations > in our upstream git repository. Many of the "old" contributors still > supply their new translations by committing directly into our > repository. This had lead to a need for merging between the launchpad > translations and our upstream ones. That's a problem on it's own: i.e. it's basically impossible to do a correct merge if someone is working on the same translation in two places: manual overriding is then a must. I'd actually wonder why wouldn't your "old" contributors simply use the PO file upload feature in Launchpad instead? Maybe that's not exactly as easy for them as doing a commit, but it shouldn't be too hard either. The problems you may hit with your current approach are too many, and at least all 'bigger' translation projects that I know of make translation exclusive to a single team. I.e. you can get into a situation where a disagreement occurs, and none of the sides wants to back down. You, as a project maintainer, wouldn't be able to say which translation is 'better', because you are not a native speaker of the language (and even if you are, it's sometimes tricky). So, you can have people doing it in one way in Launchpad, and in another way directly in your source code. So, my suggestion would be to switch all your contributors to Launchpad. > However: > > One of our translators pointed out the requirement that all launchpad > translations are under the BSD license. This poses us some problems. > gEDA is GPL, and our existing translations are GPL. It also seems very > problematic to track which strings are exported from launchpad, and thus > covered by a BSD license. (I'm also unsure if the project is happy with > mixed licensing or not). In general, you can reuse BSD licensed translations in GPL programs, and that's why we decided to go with BSD license in the first place (you can reuse them in all other projects as well, be it under LGPL, GPL, BSD or MPL). > Even if tracking the licenses of individual strings were possible, the > need to merge / update with upstream presents a headache. As explained above, it's a headache for more important reasons than licensing. IMHO, at least. There can be no automated system which will support that in a good way, because there is no 'good way' to do it. > The only > workflow I know this to be possible with, is exporting the launchpad > translations, me manually merging changes against the git repository, > then re-importing the translations as an upstream published set in > launchpad. AIUI, this will mark all the strings as GPL (coming from > gEDA), even those which actually originate from Launchpad. Indeed. Going back and forth by merging translations is not the right way to do it. However, it should not pose a problem as far as translations and their license marking are concerned, since they'll still be correctly marked as originating in LP (this is not user visible, but we keep that inside the DB). > I don't see how we can merge those translations back into our git > repository and still keep track of the licensing for each translation. > Similarly, we can't - without asking ALL our translation contributors, > just say "lets make all gEDA translations BSD licensed". There's no need to do that. > IMO, having launchpad contributers submit translations under the BSD > license is a mistake, and launchpad should have gone down the "public > domain" route with their translations. For all practical purposes, BSD is exactly the same as public domain, and that's another reason why we chose it. And we didn't use 'public domain' so people would still keep some control of their translations (they generally call that "moral copyrights", which are non exclusive). > Even then, it isn't clear > if we could take public domain translations (no restrictions on use), > then declare them part of a GPL set. (Perhaps mean spirited, even if it > were possible). Yes, you can, and you can do that with BSD as well. > Would it be possible have translations submitted under a license > allowing us to relicense suggested strings as GPL V2+ (for example?) You mention yourself how it's a mess to keep track of translations with two different licenses. And in Launchpad, we offer suggestions across the system, so imagine how hard it'd be to do it with 20+ licenses and millions of translation messages. Anyway, you should not worry about this, since you can include BSD licensed translations in GPL project without any problem. > Could Canonical consider requesting authors submit their transations > giving Canonical / whoever, free permission to re-license them under ANY > OSI approved license. (Or with the BSD theme... any license?) This extra > permission could be available as an additional option when submitting > strings. To actually get that permission (and for it to have any legal meaning whatsoever), one would need a real signed (on-paper) assignment from the translator, and you can imagine how Canonical doesn't want to do that. :) > Would it be possible to allow individual projects to have their own > translation licenses? IE. could people translating strings for gEDA > using Launchpad dual-license those provided strings with the GPL (and to > Canonical under the BSD license if required)? This would be useful to > use, EVEN if we couldn't access other BSD licensed string suggestions, > if it would keep the output .po files GPL V2+ licensed. See above. We'd have to change our system in a lot of ways, and it would be hard work. And would make the system much slower (we are operating with huge amounts of data), and the benefit would be small. In general, we have discussed the BSD license at length, and it exactly allows you to do what you want to do. > If not, I guess the only thing we can do to keep things sane (legally), > would be to: > > 1. Drop all launchpad translated strings from gEDA (I still haven't got > round to handling the merge nightmare, so as yet - no launchpad > translations have made it back upstream.) I expect that to be a problem mostly because of the merging issues itself, not because of licensing. In general, if you've used LP exclusively for your translations, you would have neither licensing neither merging problems (i.e. it'd be easy to find which messages are done directly in LP, and contain a different license). Also, there's an easier way for you to do a merge: just upload PO files from your source code into Launchpad as 'published uploads'. Launchpad will 'merge' both translations, though it will give preference to those done in Launchpad (you can easily find and revert to those from uploaded PO files by using 'changed in LP' filter and 'Packaged:' suggestions). Then just export them back, and you'll have merged translations. Cheers, Danilo
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)