[PATCH 3/5] localedata: CLDRv28: update LC_ADDRESS.country_name translations

[Mike Frysinger]

On 11 Feb 2016 10:04, Carlos O'Donell wrote:
> On 02/11/2016 04:24 AM, Florian Weimer wrote:
> > On 02/11/2016 05:27 AM, Carlos O'Donell wrote:
> >> On 02/10/2016 03:12 PM, Mike Frysinger wrote:
> >>> then it would be obvious what version of CLDR was used to update the
> >>> locale.  the downside is that the file isn't 100% sourced from CLDR,
> >>> so it seems like clobbering all the fields is wrong ?
> >>
> >> Per FSF statement [1] the locale files are not copyrightable so IMO
> >> attribution matters only so much as we care to thank the previous
> >> authors for their work. Such previous authors already have attribution
> >> in the Changelog, and IMO need not have any more attribution in the
> >> source file, just like we don't use "Contributed by" anymore.
> > 
> > unicode.org claims copyright on CLDR data:
> > 
> >   <http://unicode.org/repos/cldr/trunk/unicode-license.txt>
> > 
> > The terms do not appear to be too onerous, but I would recommend to
> > obtain FSF (and internal) sign-off before incorporating data directly
> > from CLDR into glibc.
> 
> Does this position not make it clear?
> https://sourceware.org/ml/libc-locales/2013-q1/msg00048.html
> 
> For the Unicode 8.0 update and this CLDR update we should be
> stripping all conflicting copyright notices and adding:
> 
> % This file is part of the GNU C Library and contains locale data.
> % The Free Software Foundation does not claim any copyright interest
> % in the locale data contained in this file.  The foregoing does not
> % affect the license of the GNU C Library as a whole.  It does not
> % exempt you from the conditions of the license if your use would
> % otherwise be governed by that license.
> 
> Per the FSF request?
> 
> I don't see that we need to keep making legal requests unless the
> FSF changes their position.

makes sense to me

i'm hacking on a linter of sorts for the locale data files to check for
common issues.  i can add this logic to that.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160211/7804f0fb/attachment.sig>