This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.
> > 
> > claims copyright on CLDR data:
> > 
> >   <>
> > 
> > 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?
> 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.

Attachment: signature.asc
Description: Digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]