[Bug localedata/11213] localedata licencing issues

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

Jonathan Nieder <jrnieder at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jrnieder at gmail dot com

--- Comment #2 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-13 17:49:34 UTC ---
Work in progress is being tracked at
http://www.helgefjell.de/debianitem.php?name=bug555168

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[tg at mirbsd dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #4 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-13 20:48:02 UTC ---
As long as it’s not an explicit Public Domain (which is probably
illegal), much would be fine with me.

For example, something like this:

Copyright © 2010, 2011, 2012
→       Foo M. Bar <fbar@baz.org>

This locale information is available under any Open Source licence
approved by the OSI, at your choice.

(Possibly also all OKFN approved licences, if you feel like that.)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[cjlhomeaddress at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

Chris Leonard <cjlhomeaddress at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cjlhomeaddress at gmail dot
                   |                            |com

--- Comment #3 from Chris Leonard <cjlhomeaddress at gmail dot com> 2012-07-13 20:41:05 UTC ---
As someone working on several new locales, it would help if you could provide
an example copyright line for the file header that would be considered "ideal".

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[tg at mirbsd dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #6 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-13 21:10:39 UTC ---
Explicit PD alone is *not* enough, it's non-free: it lacks an explicit
copyright licence, and since the Berne Convention, all works are automatically
under copyright protection. Saying a work is PD isn't possible in all
jurisdictions.

If you absolutely must insist on PD, I really insist on you including a
paragraph similar to the following too:

.\" In countries where the Public Domain status of the work may not be
.\" valid, its primary author hereby grants a copyright licence to the
.\" general public to deal in the work without restriction and permis-
.\" sion to sublicence derivates under the terms of any (OSI approved)
.\" Open Source licence.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #5 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-13 21:02:26 UTC ---
(In reply to comment #4)
> As long as it’s not an explicit Public Domain (which is probably
> illegal), much would be fine with me.

Heh, I was about to post the following:

| I'm fond of
|
|  % This file has been put in the public domain.
|  % You can do whatever you want with this file.
|  %
|  % Author: Chris Leonard
|
| Some[*] might object that under some systems of law, there is no such
| thing as putting a work in the public domain.  These people would be
| right.  Luckily the above wording makes the intent clear and
| unambiguous enough that reasonable courts recognize it as a license
| grant.
|
| [*] http://www.rosenlaw.com/lj16.htm
|     Rebuttal: http://cr.yp.to/publicdomain.html
|
| If you want to dodge that issue, here's another reasonable way to go:
|
| % Copyright © 2012 Chris Leonard
| % License: Zlib <http://www.zlib.net/zlib_license.html>

Thorsten's "any OSI-approved license" is fine, too.  Even something
that requires reproducing a disclaimer of warranty like the LGPL, GPL,
Expat license, or a two-clause BSD-style license is fine, though it
seems silly for locale data.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[tg at mirbsd dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #8 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-15 14:20:36 UTC ---
CC0 would be fine, but OSI has decided to not approve it at the moment.

People raised concerns about things like patent grants, and it was decided to
further discuss, especially as CC is in the process of working on the next
version of their other licences at the moment, and to revisit that later. (For
what it’s worth, I voted in favour of approving CC0.)

As long as only things like FSF and DFSG compatibility are a goal, that
shouldn’t stop you, but having OSI approval has, in the past, helped any sort
of licencing issue.

Now, I’d suggest https://www.mirbsd.org/MirOS-Licence.htm which *is* OSI
approved *and* FSF and DFSG compatible *and* can be used for code, data and any
other kind of copyrightable work. (Disclaimer: that’s mine, so I’m biased.
Although I’ve published criteria a lawyer-written copycenter-style licence must
fulfil for me to disrecommend this one in favour of the new one.)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[cjlhomeaddress at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #7 from Chris Leonard <cjlhomeaddress at gmail dot com> 2012-07-15 13:56:04 UTC ---
(In reply to comment #6)
> Explicit PD alone is *not* enough, it's non-free: it lacks an explicit
> copyright licence, and since the Berne Convention, all works are automatically
> under copyright protection. Saying a work is PD isn't possible in all
> jurisdictions.
> 
> If you absolutely must insist on PD, I really insist on you including a
> paragraph similar to the following too:
> 
> .\" In countries where the Public Domain status of the work may not be
> .\" valid, its primary author hereby grants a copyright licence to the
> .\" general public to deal in the work without restriction and permis-
> .\" sion to sublicence derivates under the terms of any (OSI approved)
> .\" Open Source licence.

If "Public Domain" like is a goal, is there any problem with CC-zero

http://creativecommons.org/publicdomain/zero/1.0/

or does CC-0 fail to overcome the absense of public domain status in certain
juridictions?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #9 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-15 16:00:40 UTC ---
(In reply to comment #7)
> If "Public Domain" like is a goal, is there any problem with CC-zero
>
> http://creativecommons.org/publicdomain/zero/1.0/

These are matters of taste.  Practically speaking, any free software
license is probably line.  Any GPL-compatible license is certainly
fine.

I can't stop you, but CC-zero is a pain in the neck because its text
is very long. Is "Public Domain"-like your goal? Anyway, we've gone
off-topic for this bugtracker --- feel free to contact me and Thorsten
by email and cc some mailing list of your choice and we can guide you
through the process of choosing a license that matches your intent.

If you just want a default for locales in glibc, LGPL-2.1+ ("the license
of glibc") is probably what most people were assuming the locales already
had.  A license notice can look like this:

 % Copyright © 2012, Chris Leonard
 % This file is free software; you can redistribute it and/or modify
 % it under the terms of the GNU Lesser General Public License; either
 % version 2.1 of the License, or (at your option) any later version.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #13 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-15 19:05:10 UTC ---
Hi Eben et al,

Petr Baudis wrote:

> I'm sorry, I didn't realize the presence of this bug earlier. We have made some
> research regarding this on the mailing list some time ago and this is currently
> the opinion of FSF on the matter:
>
>   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
>
> I.e., locale data is not copyrightable, therefore it cannot be covered by any
> licence and that is also the reason we do not require copyright assignment
> paperwork from the locale authors.
>
> If you (e.g. Debian project) disagree, I encourage you to contact
> copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
> this situation really is the best outcome since no paperwork is needed, I'd
> say. My opinion is that the outcome of this bug should be removal of licence
> notices (and "copyright" notices) from all localedata files to clear up any
> possible confusion - comments?

Legal question for you.

Along with everything else it contains, the GNU C library provides a
collection of locale data.  Localedata files include basic information
about how programs should interact with users in a particular area:
currency symbols, paper size, which encoding to use for text files,
translations for "yes" and "no", and other details like that.  You can
find the glibc locales in the localedata/locales directory of glibc:

  http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales

For example, the English locale for the United States is available
from the following address.

 
http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US

Since this is mostly factual information without much creative
content, no one paid much mind to its license.  Many locales permit
use, distribution, and commercial use without permitting modification:

    # Distribution and use is free, also for
    # commercial purposes.

Most notably, the POSIX locale contains that notice.  Some are more
philosophical:

    % Distribution and use is

Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
Debian project[1].

We are concerned that although these files do not contain much
creative content, they do contain some, for example in their comments.
We are generally not lawyers and do not know what does and doesn't
fall under copyright protection in the United States and elsewhere.
It is important for it to be very clear to both us and our users what
their rights are.

Helge (cc-ed) has taken a survey of authors of locales with the notice
that doesn't permit modification to find what license terms they
intend.  Some findings:

 - many locale authors expected that, as part of glibc, these
   would have the same license as glibc (LGPL-2.1+)

 - they did not intend to forbid modification, and the notice was
   propagated from the POSIX locale by copy and paste.

 - when asked what terms they would like going forward for their work,
   most prefer "public domain", followed by LGPL and GPL.

You can find a summary of Helge's efforts at [2], and the actual
emails are at [1].

Unlike most of glibc, the FSF has not historically required copyright
assignment for these files.  Independently of the above investigation,
they were recently asked about and reaffirmed this position[3]:

    Well that was fast. The SFLC said that this type of thing isn't
copyrightable, and that 
    paperwork isn't really necessary. So we should be good to go. Thank you so
much for all your 
    help.

Questions:

 - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
   copyright notices.  Are we legally permitted to remove the
   notices or to change them to say "Authors: ..."?

 - Suppose I wanted to add the text "You may freely use, modify,
   distribute, and relicense this file" to each of the locale data
   files, to make it completely clear that users are free to
   incorporate text from them into differently licensed works.  Would
   that be legally permissible?  Would it be accurate?  Is there any
   reason not to do it?

 - When locale authors have stated a preferred license, is there value
   in documenting that, or would it be counterproductive?

 - If the legal heir to some author of many locales wants to be really
   nasty, what is the worst they can do on the basis of this
   contribution?

Thanks in advance for looking this over.

Sincerely,
Jonathan

[1] http://bugs.debian.org/555168
[2] http://www.helgefjell.de/debianitem.php?name=bug555168
[3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Bug localedata/11213] localedata licencing issues

[Keld Simonsen]

Hmm, I contributed a number of locales. I always assumed that there was a copyright to each of them.
I do hold a masters in legislate law.

In my work, there was a considerable amount of labour. My initial work was about 100 pages for
the POSIX standard 1003.2 back in 1993.  The expression was quite inventive at the time (IMHO) 
and it had a number of facilities, such as being able to be run in many character sets,
it was character set independent - which was a novelty then and interesting, because
we has so many charsets then, and not almost just UTF8 as of today. It was 20 years ago!

Also the machinery had an elaborate set of character names that had had quite some design
work for it to be mnemnoninc. The sorting was an innovative way of sorting almost
all of the characters (in use at that time) which had never been done before.
There was quite some work in getting the data for each country and language, and
also to get interested parties to agree on the data.
The system with locales and  charmaps and repertoiremaps itself was also quite inventive.
And just getting it to compile was also some effort. 

But then I attached a licence to it that was not compatible with OSI definitions.
I actually think the locales preceded the OSI defs in time. I wrongly thought that I
should be a kind of maste editor of all of the data, this did not work out.

I am happy with what came out of it, and all the activity and involvement from all over
the world on the glibc localedef data. I recently stated that all of the data I have
contributed is released under GPL v2. I hope this solves some problems.

With my law background I think is is not fair to say the there is no
work height in the data. I don't care too much for my own work wrt. the licences,
My aim was that the data and the work should be used, and also to maintain some quality
to the work. The data should not become flawed. The current scheme with glibc is a 
good way to ensure that - but I did not envisage that when I wrote the specs
and the license.

best regards
Keld


On Sun, Jul 15, 2012 at 07:05:10PM +0000, jrnieder at gmail dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
> 
> --- Comment #13 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-15 19:05:10 UTC ---
> Hi Eben et al,
> 
> Petr Baudis wrote:
> 
> > I'm sorry, I didn't realize the presence of this bug earlier. We have made some
> > research regarding this on the mailing list some time ago and this is currently
> > the opinion of FSF on the matter:
> >
> >   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
> >
> > I.e., locale data is not copyrightable, therefore it cannot be covered by any
> > licence and that is also the reason we do not require copyright assignment
> > paperwork from the locale authors.
> >
> > If you (e.g. Debian project) disagree, I encourage you to contact
> > copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
> > this situation really is the best outcome since no paperwork is needed, I'd
> > say. My opinion is that the outcome of this bug should be removal of licence
> > notices (and "copyright" notices) from all localedata files to clear up any
> > possible confusion - comments?
> 
> Legal question for you.
> 
> Along with everything else it contains, the GNU C library provides a
> collection of locale data.  Localedata files include basic information
> about how programs should interact with users in a particular area:
> currency symbols, paper size, which encoding to use for text files,
> translations for "yes" and "no", and other details like that.  You can
> find the glibc locales in the localedata/locales directory of glibc:
> 
>   http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
> 
> For example, the English locale for the United States is available
> from the following address.
> 
>  
> http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US
> 
> Since this is mostly factual information without much creative
> content, no one paid much mind to its license.  Many locales permit
> use, distribution, and commercial use without permitting modification:
> 
>     # Distribution and use is free, also for
>     # commercial purposes.
> 
> Most notably, the POSIX locale contains that notice.  Some are more
> philosophical:
> 
>     % Distribution and use is
> 
> Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
> Debian project[1].
> 
> We are concerned that although these files do not contain much
> creative content, they do contain some, for example in their comments.
> We are generally not lawyers and do not know what does and doesn't
> fall under copyright protection in the United States and elsewhere.
> It is important for it to be very clear to both us and our users what
> their rights are.
> 
> Helge (cc-ed) has taken a survey of authors of locales with the notice
> that doesn't permit modification to find what license terms they
> intend.  Some findings:
> 
>  - many locale authors expected that, as part of glibc, these
>    would have the same license as glibc (LGPL-2.1+)
> 
>  - they did not intend to forbid modification, and the notice was
>    propagated from the POSIX locale by copy and paste.
> 
>  - when asked what terms they would like going forward for their work,
>    most prefer "public domain", followed by LGPL and GPL.
> 
> You can find a summary of Helge's efforts at [2], and the actual
> emails are at [1].
> 
> Unlike most of glibc, the FSF has not historically required copyright
> assignment for these files.  Independently of the above investigation,
> they were recently asked about and reaffirmed this position[3]:
> 
>     Well that was fast. The SFLC said that this type of thing isn't
> copyrightable, and that 
>     paperwork isn't really necessary. So we should be good to go. Thank you so
> much for all your 
>     help.
> 
> Questions:
> 
>  - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
>    copyright notices.  Are we legally permitted to remove the
>    notices or to change them to say "Authors: ..."?
> 
>  - Suppose I wanted to add the text "You may freely use, modify,
>    distribute, and relicense this file" to each of the locale data
>    files, to make it completely clear that users are free to
>    incorporate text from them into differently licensed works.  Would
>    that be legally permissible?  Would it be accurate?  Is there any
>    reason not to do it?
> 
>  - When locale authors have stated a preferred license, is there value
>    in documenting that, or would it be counterproductive?
> 
>  - If the legal heir to some author of many locales wants to be really
>    nasty, what is the worst they can do on the basis of this
>    contribution?
> 
> Thanks in advance for looking this over.
> 
> Sincerely,
> Jonathan
> 
> [1] http://bugs.debian.org/555168
> [2] http://www.helgefjell.de/debianitem.php?name=bug555168
> [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
> 
> -- 
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #11 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-15 18:16:16 UTC ---
(In reply to comment #10)
> I'm sorry, I didn't realize the presence of this bug earlier. We have made
> some research regarding this on the mailing list some time ago and this is
> currently the opinion of FSF on the matter:
>
>   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
>
> I.e., locale data is not copyrightable, therefore it cannot be covered by any
> licence and that is also the reason we do not require copyright assignment
> paperwork from the locale authors.

I guess one approach would be to scrub all the comments out of these files
so all that is left is the locale data?

Though I wouldn't be too thrilled with that.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[tg at mirbsd dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #12 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-15 18:28:07 UTC ---
Indeed, the concern was raised in Debian (I stumbled upon it), so the SFLC/FSF
opinion is not enough to close this “as is”.

However, if the information from the mail you linked is correct, and the data
really consists only of uncopyrightable information, I personally (not speaking
for Debian) believe your way of resolving this (by removing the notices; I’d
notify the people involved though) is valid.

Jonathan, simply commenting the data does not necessarily add enough “work” to
fall under Copyright protection.

/me looks at
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=wo_SN;att=1;bug=555168
for example, now

This example indeed looks uncopyrightable (but the notion of “being put into PD
by its author” is offensive). If the others are like this, I hope Debian will
accept the resolution that the problem is not in the inconsistent notices but
that there have been notices put on such data at all. (Note, IANAL, and I don’t
speak for the Debian glibc maintainers or ftpmasters or legal people.)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[pasky at ucw dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

Petr Baudis <pasky at ucw dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pasky at ucw dot cz

--- Comment #10 from Petr Baudis <pasky at ucw dot cz> 2012-07-15 18:13:01 UTC ---
I'm sorry, I didn't realize the presence of this bug earlier. We have made some
research regarding this on the mailing list some time ago and this is currently
the opinion of FSF on the matter:

  http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html

I.e., locale data is not copyrightable, therefore it cannot be covered by any
licence and that is also the reason we do not require copyright assignment
paperwork from the locale authors.

If you (e.g. Debian project) disagree, I encourage you to contact
copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
this situation really is the best outcome since no paperwork is needed, I'd
say. My opinion is that the outcome of this bug should be removal of licence
notices (and "copyright" notices) from all localedata files to clear up any
possible confusion - comments?

(Which is something I'm not likely to engage myself with as my localedata TODO
backlog is sufficiently long already, but maybe it is important enough for some
downstream projects like Debian to contribute such a patch, if they share this
view?)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #14 from keld at keldix dot com <keld at keldix dot com> 2012-07-16 00:42:03 UTC ---
Hmm, I contributed a number of locales. I always assumed that there was a
copyright to each of them.
I do hold a masters in legislate law.

In my work, there was a considerable amount of labour. My initial work was
about 100 pages for
the POSIX standard 1003.2 back in 1993.  The expression was quite inventive at
the time (IMHO) 
and it had a number of facilities, such as being able to be run in many
character sets,
it was character set independent - which was a novelty then and interesting,
because
we has so many charsets then, and not almost just UTF8 as of today. It was 20
years ago!

Also the machinery had an elaborate set of character names that had had quite
some design
work for it to be mnemnoninc. The sorting was an innovative way of sorting
almost
all of the characters (in use at that time) which had never been done before.
There was quite some work in getting the data for each country and language,
and
also to get interested parties to agree on the data.
The system with locales and  charmaps and repertoiremaps itself was also quite
inventive.
And just getting it to compile was also some effort. 

But then I attached a licence to it that was not compatible with OSI
definitions.
I actually think the locales preceded the OSI defs in time. I wrongly thought
that I
should be a kind of maste editor of all of the data, this did not work out.

I am happy with what came out of it, and all the activity and involvement from
all over
the world on the glibc localedef data. I recently stated that all of the data I
have
contributed is released under GPL v2. I hope this solves some problems.

With my law background I think is is not fair to say the there is no
work height in the data. I don't care too much for my own work wrt. the
licences,
My aim was that the data and the work should be used, and also to maintain some
quality
to the work. The data should not become flawed. The current scheme with glibc
is a 
good way to ensure that - but I did not envisage that when I wrote the specs
and the license.

best regards
Keld


On Sun, Jul 15, 2012 at 07:05:10PM +0000, jrnieder at gmail dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
> 
> --- Comment #13 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-15 19:05:10 UTC ---
> Hi Eben et al,
> 
> Petr Baudis wrote:
> 
> > I'm sorry, I didn't realize the presence of this bug earlier. We have made some
> > research regarding this on the mailing list some time ago and this is currently
> > the opinion of FSF on the matter:
> >
> >   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
> >
> > I.e., locale data is not copyrightable, therefore it cannot be covered by any
> > licence and that is also the reason we do not require copyright assignment
> > paperwork from the locale authors.
> >
> > If you (e.g. Debian project) disagree, I encourage you to contact
> > copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
> > this situation really is the best outcome since no paperwork is needed, I'd
> > say. My opinion is that the outcome of this bug should be removal of licence
> > notices (and "copyright" notices) from all localedata files to clear up any
> > possible confusion - comments?
> 
> Legal question for you.
> 
> Along with everything else it contains, the GNU C library provides a
> collection of locale data.  Localedata files include basic information
> about how programs should interact with users in a particular area:
> currency symbols, paper size, which encoding to use for text files,
> translations for "yes" and "no", and other details like that.  You can
> find the glibc locales in the localedata/locales directory of glibc:
> 
>   http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
> 
> For example, the English locale for the United States is available
> from the following address.
> 
>  
> http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US
> 
> Since this is mostly factual information without much creative
> content, no one paid much mind to its license.  Many locales permit
> use, distribution, and commercial use without permitting modification:
> 
>     # Distribution and use is free, also for
>     # commercial purposes.
> 
> Most notably, the POSIX locale contains that notice.  Some are more
> philosophical:
> 
>     % Distribution and use is
> 
> Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
> Debian project[1].
> 
> We are concerned that although these files do not contain much
> creative content, they do contain some, for example in their comments.
> We are generally not lawyers and do not know what does and doesn't
> fall under copyright protection in the United States and elsewhere.
> It is important for it to be very clear to both us and our users what
> their rights are.
> 
> Helge (cc-ed) has taken a survey of authors of locales with the notice
> that doesn't permit modification to find what license terms they
> intend.  Some findings:
> 
>  - many locale authors expected that, as part of glibc, these
>    would have the same license as glibc (LGPL-2.1+)
> 
>  - they did not intend to forbid modification, and the notice was
>    propagated from the POSIX locale by copy and paste.
> 
>  - when asked what terms they would like going forward for their work,
>    most prefer "public domain", followed by LGPL and GPL.
> 
> You can find a summary of Helge's efforts at [2], and the actual
> emails are at [1].
> 
> Unlike most of glibc, the FSF has not historically required copyright
> assignment for these files.  Independently of the above investigation,
> they were recently asked about and reaffirmed this position[3]:
> 
>     Well that was fast. The SFLC said that this type of thing isn't
> copyrightable, and that 
>     paperwork isn't really necessary. So we should be good to go. Thank you so
> much for all your 
>     help.
> 
> Questions:
> 
>  - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
>    copyright notices.  Are we legally permitted to remove the
>    notices or to change them to say "Authors: ..."?
> 
>  - Suppose I wanted to add the text "You may freely use, modify,
>    distribute, and relicense this file" to each of the locale data
>    files, to make it completely clear that users are free to
>    incorporate text from them into differently licensed works.  Would
>    that be legally permissible?  Would it be accurate?  Is there any
>    reason not to do it?
> 
>  - When locale authors have stated a preferred license, is there value
>    in documenting that, or would it be counterproductive?
> 
>  - If the legal heir to some author of many locales wants to be really
>    nasty, what is the worst they can do on the basis of this
>    contribution?
> 
> Thanks in advance for looking this over.
> 
> Sincerely,
> Jonathan
> 
> [1] http://bugs.debian.org/555168
> [2] http://www.helgefjell.de/debianitem.php?name=bug555168
> [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
> 
> -- 
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #15 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-16 01:13:54 UTC ---
Hi Keld,

Keld Simonsen wrote[1]:

> Hmm, I contributed a number of locales. I always assumed that there was a
> copyright to each of them.
> I do hold a masters in legislate law.
[lots of helpful background snipped, including the intent of the
original notice]

Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
automatically receive mails to that bug tracker.

My guess is that the FSF's concerns that prompted the "this type of
thing isn't copyrightable" answer were USA-centric.  If I remember
correctly, in some jurisdictions outside the United States, the
eligibility of a work for copyright is based on the amount of work put
into it (as you remind me), while in the United States it's based on a
concept of creativity.

(For the curious: I personally would be happiest if the FSF would
continue not to care about these works' copyright while everyone else
would consider them as possibly copyrighted.  That way there is no
need for copyright assignment --- less paperwork! --- but there would
be no excuse not to follow the usual free software practice of
documenting the explicit permission grants the authors provide.)

Jonathan

[1] http://sourceware.org/PR11213#c14

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #16 from keld at keldix dot com <keld at keldix dot com> 2012-07-16 08:56:10 UTC ---
On Sun, Jul 15, 2012 at 08:13:31PM -0500, Jonathan Nieder wrote:
> Hi Keld,
> 
> Keld Simonsen wrote[1]:
> 
> > Hmm, I contributed a number of locales. I always assumed that there was a
> > copyright to each of them.
> > I do hold a masters in legislate law.
> [lots of helpful background snipped, including the intent of the
> original notice]
> 
> Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
> automatically receive mails to that bug tracker.
> 
> My guess is that the FSF's concerns that prompted the "this type of
> thing isn't copyrightable" answer were USA-centric.  If I remember
> correctly, in some jurisdictions outside the United States, the
> eligibility of a work for copyright is based on the amount of work put
> into it (as you remind me), while in the United States it's based on a
> concept of creativity.

I claim that there is a lot of creativity in how the locales are written, at
least
the big ones.  As said one of my intial works were 100 pages of the POSIX.2
standard.
And then the locales grew even further, with the advent of full ISO 10646
(Unicode)
coverage and ISO TR 14652 extra categories.  There is a lot of design and
ideas, 
and a lot of design criteria in the locales. Including a number of theoretical
landmarks,
and something that could have been patentetd, if somebody were inclined to do
such nasty things:-)
And IMHO that has resulted in a system that still has a number of advantages
over
what big players in the market have done for i18n. 

And then there is compilation copyright according to the Berne convention -
maybe you
don't hold copyright on the data, but you hold copyright on the presentation on
it and the
collection of the combination of the data.

I would say in juridical terms it would not be safe to assume that there is no
copyright on
the locales (and charmaps and repertoiremaps).

Best regards
keld

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[pasky at ucw dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #17 from Petr Baudis <pasky at ucw dot cz> 2012-07-16 11:44:25 UTC ---
Keld, I certainly agree that there is a lot of creativity in the way you
designed the locales specification. However, to me that would imply a copyright
on the specification and copyright on the implementation. Individual localedata
files that simply follow the pre-defined format and contain commonly known
facts seem to be a different matter to me?

The compilation copyright seems like a more serious issue.

(Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm
looking to a statement from someone at FSF/SFLC.)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Bug localedata/11213] localedata licencing issues

[Keld Simonsen]

On Mon, Jul 16, 2012 at 11:44:25AM +0000, pasky at ucw dot cz wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
> 
> --- Comment #17 from Petr Baudis <pasky at ucw dot cz> 2012-07-16 11:44:25 UTC ---
> Keld, I certainly agree that there is a lot of creativity in the way you
> designed the locales specification. However, to me that would imply a copyright
> on the specification and copyright on the implementation. Individual localedata
> files that simply follow the pre-defined format and contain commonly known
> facts seem to be a different matter to me?
> 
> The compilation copyright seems like a more serious issue.
> 
> (Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm
> looking to a statement from someone at FSF/SFLC.)

I did not create the original POSIX specification of locale and charmap formats,
one of the main people behind that was Gary Miller, and for the sorting Greger Leijonhufvud. 
I was the main contributor for the ISO TR 14652 extensions. 

Anyway what I wrote for POSIX.2 was the localedata - not the specification of the formats.
This was what later became the da_DK and the i18n locales - that is pure localedata data.
And there was a lot of design and creativity in that. So it is not just the design 
that has work height - also the *data* has.

Then filling in data in the locale format - how much work height is there in that?
I don't know. I think it may be that same problem of how much creativity there is in
providing patches in general to OSS. Is it just a spelling creation? Or what?
I once provided a patch of just 1 line to the Linux kernel. It took quite some research and
some imagnation how to do it and development of new of theory,
and I probably could have patented that mechanism.
In some cases that patch could speed up performance with 50 %
So you cannot judge work height by the size of the contribution.

best regards
keld

[Bug localedata/11213] localedata licencing issues

[tg at mirbsd dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #18 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-16 13:13:31 UTC ---
Keld, while you may have had a lot of “sweat of brow”, in the end, the locale
data (in the one file I looked at) is mere fact, and there is, basically, only
one way to express such facts using the format glibc expects. This is, at
least, under the EU interoperability directive, not copyrightable (neither are
*.h files, unless they include insane amounts of inline functions, by the way).
As for the USA, you probably know that better than I do, but the work, while it
may have cost you a lot of creativity, is mostly “sweat of brow”, to express
the fact that way. You may have designed the interface, the character naming
convention, etc. but these are interfaces, not works in the sense of copyright.
I really do not want you to lose any attribution of that, but I don’t believe
the (one file I looked at with) locale information as shown is not
copyrightable.

“something that could have been patentetd”[sic] is of different scope than
copyright relevant work. I also fear you could probably have patented it, but
not put it under copyright protection. (Jonathan, mere effort is also not
enough in Germany, although USA’s “sweat of brow” doctrine is a tad stronger.
Still, we’re facing interoperability interfaces here, and mere fact; the
currency of the USA is the Dollar, no matter what.)

The presentation and combination of the data may, may, be affected by copyright
or even database law, true. I guess SFLC and, if possible, international
lawyers could have a look at that.

I laud your attempt to keep quality, but IMHO, using legal matters for that is
not the way to go. You could run a “locale data repository”, from which e.g.
glibc could then pull, for that, like tzdata.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Bug localedata/11213] localedata licencing issues

[Keld Simonsen]

On Mon, Jul 16, 2012 at 01:13:31PM +0000, tg at mirbsd dot de wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
> 
> --- Comment #18 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-16 13:13:31 UTC ---
> Keld, while you may have had a lot of ???sweat of brow???, in the end, the locale
> data (in the one file I looked at) is mere fact, and there is, basically, only
> one way to express such facts using the format glibc expects.

Yes, some of the locales are stright forward. But if you look at the whole
combination of a locale, with the LC_COLLATE, the LC_CTYPE, and the transliteration
specs, there is not only sweat in it but a lot of decisions.
Even the LC_MESSAGES data for yes and no contains a number of variations to consider.
And even the LC_TIME has some tricks. The choices is a common subject we talk about on the
localedata reflector, because there are different ways of doing a lot of
things in the locale data. And when there is choice, there is creativity
and work height.

> This is, at
> least, under the EU interoperability directive, not copyrightable (neither are
> *.h files, unless they include insane amounts of inline functions, by the way).
> As for the USA, you probably know that better than I do, but the work, while it
> may have cost you a lot of creativity, is mostly ???sweat of brow???, to express
> the fact that way. You may have designed the interface, the character naming
> convention, etc. but these are interfaces, not works in the sense of copyright.
> I really do not want you to lose any attribution of that, but I don???t believe
> the (one file I looked at with) locale information as shown is not
> copyrightable.

(maybe too many negations here - but I think I know what you mean.)
I think there is differences of what level of work height that is needed for it to be 
copyrightable in different countries. but I would be astonished if say 1000 lines of
data with a number of serious design decisions on the solutions did not
enjoy copyright in any country (under the Berne convention)..


I do think locales per se are works. They are freestanding items, that are supposed then to
work toghether with other parts to make a functioning system.

> ???something that could have been patentetd???[sic] is of different scope than
> copyright relevant work. I also fear you could probably have patented it, but
> not put it under copyright protection. (Jonathan, mere effort is also not
> enough in Germany, although USA???s ???sweat of brow??? doctrine is a tad stronger.
> Still, we???re facing interoperability interfaces here, and mere fact; the
> currency of the USA is the Dollar, no matter what.)

:-)

best regards
keld

[Bug localedata/11213] localedata licencing issues

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #19 from keld at keldix dot com <keld at keldix dot com> 2012-07-16 16:38:28 UTC ---
On Mon, Jul 16, 2012 at 11:44:25AM +0000, pasky at ucw dot cz wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
> 
> --- Comment #17 from Petr Baudis <pasky at ucw dot cz> 2012-07-16 11:44:25 UTC ---
> Keld, I certainly agree that there is a lot of creativity in the way you
> designed the locales specification. However, to me that would imply a copyright
> on the specification and copyright on the implementation. Individual localedata
> files that simply follow the pre-defined format and contain commonly known
> facts seem to be a different matter to me?
> 
> The compilation copyright seems like a more serious issue.
> 
> (Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm
> looking to a statement from someone at FSF/SFLC.)

I did not create the original POSIX specification of locale and charmap
formats,
one of the main people behind that was Gary Miller, and for the sorting Greger
Leijonhufvud. 
I was the main contributor for the ISO TR 14652 extensions. 

Anyway what I wrote for POSIX.2 was the localedata - not the specification of
the formats.
This was what later became the da_DK and the i18n locales - that is pure
localedata data.
And there was a lot of design and creativity in that. So it is not just the
design 
that has work height - also the *data* has.

Then filling in data in the locale format - how much work height is there in
that?
I don't know. I think it may be that same problem of how much creativity there
is in
providing patches in general to OSS. Is it just a spelling creation? Or what?
I once provided a patch of just 1 line to the Linux kernel. It took quite some
research and
some imagnation how to do it and development of new of theory,
and I probably could have patented that mechanism.
In some cases that patch could speed up performance with 50 %
So you cannot judge work height by the size of the contribution.

best regards
keld

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #20 from keld at keldix dot com <keld at keldix dot com> 2012-07-16 17:04:02 UTC ---
On Mon, Jul 16, 2012 at 01:13:31PM +0000, tg at mirbsd dot de wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11213
> 
> --- Comment #18 from Thorsten Glaser <tg at mirbsd dot de> 2012-07-16 13:13:31 UTC ---
> Keld, while you may have had a lot of ???sweat of brow???, in the end, the locale
> data (in the one file I looked at) is mere fact, and there is, basically, only
> one way to express such facts using the format glibc expects.

Yes, some of the locales are stright forward. But if you look at the whole
combination of a locale, with the LC_COLLATE, the LC_CTYPE, and the
transliteration
specs, there is not only sweat in it but a lot of decisions.
Even the LC_MESSAGES data for yes and no contains a number of variations to
consider.
And even the LC_TIME has some tricks. The choices is a common subject we talk
about on the
localedata reflector, because there are different ways of doing a lot of
things in the locale data. And when there is choice, there is creativity
and work height.

> This is, at
> least, under the EU interoperability directive, not copyrightable (neither are
> *.h files, unless they include insane amounts of inline functions, by the way).
> As for the USA, you probably know that better than I do, but the work, while it
> may have cost you a lot of creativity, is mostly ???sweat of brow???, to express
> the fact that way. You may have designed the interface, the character naming
> convention, etc. but these are interfaces, not works in the sense of copyright.
> I really do not want you to lose any attribution of that, but I don???t believe
> the (one file I looked at with) locale information as shown is not
> copyrightable.

(maybe too many negations here - but I think I know what you mean.)
I think there is differences of what level of work height that is needed for it
to be 
copyrightable in different countries. but I would be astonished if say 1000
lines of
data with a number of serious design decisions on the solutions did not
enjoy copyright in any country (under the Berne convention)..


I do think locales per se are works. They are freestanding items, that are
supposed then to
work toghether with other parts to make a functioning system.

> ???something that could have been patentetd???[sic] is of different scope than
> copyright relevant work. I also fear you could probably have patented it, but
> not put it under copyright protection. (Jonathan, mere effort is also not
> enough in Germany, although USA???s ???sweat of brow??? doctrine is a tad stronger.
> Still, we???re facing interoperability interfaces here, and mere fact; the
> currency of the USA is the Dollar, no matter what.)

:-)

best regards
keld

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[cjlhomeaddress at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #21 from Chris Leonard <cjlhomeaddress at gmail dot com> 2012-07-16 18:22:04 UTC ---
I think there is something to the analogy that "glibc locale" is to "glibc" as
"PO file" is to "YOUR_PACKAGE_NAME_HERE".  Similar purposes are served in both
cases, with specific, properly-formatted information being supplied by the
localizer to allow usage of (in this case glibc) in their language.

The common licensing / copyright header lines in a PO file are:

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR OF THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.

This is certainly most localizers expectation of how their work will be
licensed and they will credited, it stands to reason that glibc locale
developers will have similar expectations, but that is merely opinion and not
in any way a legal argument.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[help at softwarefreedom dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #22 from help at softwarefreedom dot org 2012-07-16 18:49:21 UTC ---
On 07/15/2012 09:13 PM, Jonathan Nieder wrote:
> Hi Keld,
> 
> Keld Simonsen wrote[1]:
> 
>> Hmm, I contributed a number of locales. I always assumed that there was a
>> copyright to each of them.
>> I do hold a masters in legislate law.
> [lots of helpful background snipped, including the intent of the
> original notice]
> 
> Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
> automatically receive mails to that bug tracker.
> 
> My guess is that the FSF's concerns that prompted the "this type of
> thing isn't copyrightable" answer were USA-centric.  If I remember
> correctly, in some jurisdictions outside the United States, the
> eligibility of a work for copyright is based on the amount of work put
> into it (as you remind me), while in the United States it's based on a
> concept of creativity.
> 
> (For the curious: I personally would be happiest if the FSF would
> continue not to care about these works' copyright while everyone else
> would consider them as possibly copyrighted.  That way there is no
> need for copyright assignment --- less paperwork! --- but there would
> be no excuse not to follow the usual free software practice of
> documenting the explicit permission grants the authors provide.)
> 
> Jonathan
> 
> [1] http://sourceware.org/PR11213#c14


The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[help at softwarefreedom dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #22 from help at softwarefreedom dot org 2012-07-16 18:49:21 UTC ---
On 07/15/2012 09:13 PM, Jonathan Nieder wrote:
> Hi Keld,
> 
> Keld Simonsen wrote[1]:
> 
>> Hmm, I contributed a number of locales. I always assumed that there was a
>> copyright to each of them.
>> I do hold a masters in legislate law.
> [lots of helpful background snipped, including the intent of the
> original notice]
> 
> Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
> automatically receive mails to that bug tracker.
> 
> My guess is that the FSF's concerns that prompted the "this type of
> thing isn't copyrightable" answer were USA-centric.  If I remember
> correctly, in some jurisdictions outside the United States, the
> eligibility of a work for copyright is based on the amount of work put
> into it (as you remind me), while in the United States it's based on a
> concept of creativity.
> 
> (For the curious: I personally would be happiest if the FSF would
> continue not to care about these works' copyright while everyone else
> would consider them as possibly copyrighted.  That way there is no
> need for copyright assignment --- less paperwork! --- but there would
> be no excuse not to follow the usual free software practice of
> documenting the explicit permission grants the authors provide.)
> 
> Jonathan
> 
> [1] http://sourceware.org/PR11213#c14


The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

--- Comment #23 from help at softwarefreedom dot org 2012-07-16 18:50:21 UTC ---
On 07/15/2012 03:04 PM, Jonathan Nieder wrote:
> Hi Eben et al,
> 
> Petr Baudis wrote:
> 
>> I'm sorry, I didn't realize the presence of this bug earlier. We have made some
>> research regarding this on the mailing list some time ago and this is currently
>> the opinion of FSF on the matter:
>>
>>   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
>>
>> I.e., locale data is not copyrightable, therefore it cannot be covered by any
>> licence and that is also the reason we do not require copyright assignment
>> paperwork from the locale authors.
>>
>> If you (e.g. Debian project) disagree, I encourage you to contact
>> copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
>> this situation really is the best outcome since no paperwork is needed, I'd
>> say. My opinion is that the outcome of this bug should be removal of licence
>> notices (and "copyright" notices) from all localedata files to clear up any
>> possible confusion - comments?
> 
> Legal question for you.
> 
> Along with everything else it contains, the GNU C library provides a
> collection of locale data.  Localedata files include basic information
> about how programs should interact with users in a particular area:
> currency symbols, paper size, which encoding to use for text files,
> translations for "yes" and "no", and other details like that.  You can
> find the glibc locales in the localedata/locales directory of glibc:
> 
>   http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
> 
> For example, the English locale for the United States is available
> from the following address.
> 
>   http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US
> 
> Since this is mostly factual information without much creative
> content, no one paid much mind to its license.  Many locales permit
> use, distribution, and commercial use without permitting modification:
> 
> 	# Distribution and use is free, also for
> 	# commercial purposes.
> 
> Most notably, the POSIX locale contains that notice.  Some are more
> philosophical:
> 
> 	% Distribution and use is
> 
> Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
> Debian project[1].
> 
> We are concerned that although these files do not contain much
> creative content, they do contain some, for example in their comments.
> We are generally not lawyers and do not know what does and doesn't
> fall under copyright protection in the United States and elsewhere.
> It is important for it to be very clear to both us and our users what
> their rights are.
> 
> Helge (cc-ed) has taken a survey of authors of locales with the notice
> that doesn't permit modification to find what license terms they
> intend.  Some findings:
> 
>  - many locale authors expected that, as part of glibc, these
>    would have the same license as glibc (LGPL-2.1+)
> 
>  - they did not intend to forbid modification, and the notice was
>    propagated from the POSIX locale by copy and paste.
> 
>  - when asked what terms they would like going forward for their work,
>    most prefer "public domain", followed by LGPL and GPL.
> 
> You can find a summary of Helge's efforts at [2], and the actual
> emails are at [1].
> 
> Unlike most of glibc, the FSF has not historically required copyright
> assignment for these files.  Independently of the above investigation,
> they were recently asked about and reaffirmed this position[3]:
> 
> 	Well that was fast. The SFLC said that this type of thing isn't copyrightable, and that 
> 	paperwork isn't really necessary. So we should be good to go. Thank you so much for all your 
> 	help.
> 
> Questions:
> 
>  - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
>    copyright notices.  Are we legally permitted to remove the
>    notices or to change them to say "Authors: ..."?
> 
>  - Suppose I wanted to add the text "You may freely use, modify,
>    distribute, and relicense this file" to each of the locale data
>    files, to make it completely clear that users are free to
>    incorporate text from them into differently licensed works.  Would
>    that be legally permissible?  Would it be accurate?  Is there any
>    reason not to do it?
> 
>  - When locale authors have stated a preferred license, is there value
>    in documenting that, or would it be counterproductive?
> 
>  - If the legal heir to some author of many locales wants to be really
>    nasty, what is the worst they can do on the basis of this
>    contribution?
> 
> Thanks in advance for looking this over.
> 
> Sincerely,
> Jonathan
> 
> [1] http://bugs.debian.org/555168
> [2] http://www.helgefjell.de/debianitem.php?name=bug555168
> [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html

The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[help at softwarefreedom dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #22 from help at softwarefreedom dot org 2012-07-16 18:49:21 UTC ---
On 07/15/2012 09:13 PM, Jonathan Nieder wrote:
> Hi Keld,
> 
> Keld Simonsen wrote[1]:
> 
>> Hmm, I contributed a number of locales. I always assumed that there was a
>> copyright to each of them.
>> I do hold a masters in legislate law.
> [lots of helpful background snipped, including the intent of the
> original notice]
> 
> Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
> automatically receive mails to that bug tracker.
> 
> My guess is that the FSF's concerns that prompted the "this type of
> thing isn't copyrightable" answer were USA-centric.  If I remember
> correctly, in some jurisdictions outside the United States, the
> eligibility of a work for copyright is based on the amount of work put
> into it (as you remind me), while in the United States it's based on a
> concept of creativity.
> 
> (For the curious: I personally would be happiest if the FSF would
> continue not to care about these works' copyright while everyone else
> would consider them as possibly copyrighted.  That way there is no
> need for copyright assignment --- less paperwork! --- but there would
> be no excuse not to follow the usual free software practice of
> documenting the explicit permission grants the authors provide.)
> 
> Jonathan
> 
> [1] http://sourceware.org/PR11213#c14


The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

--- Comment #23 from help at softwarefreedom dot org 2012-07-16 18:50:21 UTC ---
On 07/15/2012 03:04 PM, Jonathan Nieder wrote:
> Hi Eben et al,
> 
> Petr Baudis wrote:
> 
>> I'm sorry, I didn't realize the presence of this bug earlier. We have made some
>> research regarding this on the mailing list some time ago and this is currently
>> the opinion of FSF on the matter:
>>
>>   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
>>
>> I.e., locale data is not copyrightable, therefore it cannot be covered by any
>> licence and that is also the reason we do not require copyright assignment
>> paperwork from the locale authors.
>>
>> If you (e.g. Debian project) disagree, I encourage you to contact
>> copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
>> this situation really is the best outcome since no paperwork is needed, I'd
>> say. My opinion is that the outcome of this bug should be removal of licence
>> notices (and "copyright" notices) from all localedata files to clear up any
>> possible confusion - comments?
> 
> Legal question for you.
> 
> Along with everything else it contains, the GNU C library provides a
> collection of locale data.  Localedata files include basic information
> about how programs should interact with users in a particular area:
> currency symbols, paper size, which encoding to use for text files,
> translations for "yes" and "no", and other details like that.  You can
> find the glibc locales in the localedata/locales directory of glibc:
> 
>   http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
> 
> For example, the English locale for the United States is available
> from the following address.
> 
>   http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US
> 
> Since this is mostly factual information without much creative
> content, no one paid much mind to its license.  Many locales permit
> use, distribution, and commercial use without permitting modification:
> 
> 	# Distribution and use is free, also for
> 	# commercial purposes.
> 
> Most notably, the POSIX locale contains that notice.  Some are more
> philosophical:
> 
> 	% Distribution and use is
> 
> Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
> Debian project[1].
> 
> We are concerned that although these files do not contain much
> creative content, they do contain some, for example in their comments.
> We are generally not lawyers and do not know what does and doesn't
> fall under copyright protection in the United States and elsewhere.
> It is important for it to be very clear to both us and our users what
> their rights are.
> 
> Helge (cc-ed) has taken a survey of authors of locales with the notice
> that doesn't permit modification to find what license terms they
> intend.  Some findings:
> 
>  - many locale authors expected that, as part of glibc, these
>    would have the same license as glibc (LGPL-2.1+)
> 
>  - they did not intend to forbid modification, and the notice was
>    propagated from the POSIX locale by copy and paste.
> 
>  - when asked what terms they would like going forward for their work,
>    most prefer "public domain", followed by LGPL and GPL.
> 
> You can find a summary of Helge's efforts at [2], and the actual
> emails are at [1].
> 
> Unlike most of glibc, the FSF has not historically required copyright
> assignment for these files.  Independently of the above investigation,
> they were recently asked about and reaffirmed this position[3]:
> 
> 	Well that was fast. The SFLC said that this type of thing isn't copyrightable, and that 
> 	paperwork isn't really necessary. So we should be good to go. Thank you so much for all your 
> 	help.
> 
> Questions:
> 
>  - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
>    copyright notices.  Are we legally permitted to remove the
>    notices or to change them to say "Authors: ..."?
> 
>  - Suppose I wanted to add the text "You may freely use, modify,
>    distribute, and relicense this file" to each of the locale data
>    files, to make it completely clear that users are free to
>    incorporate text from them into differently licensed works.  Would
>    that be legally permissible?  Would it be accurate?  Is there any
>    reason not to do it?
> 
>  - When locale authors have stated a preferred license, is there value
>    in documenting that, or would it be counterproductive?
> 
>  - If the legal heir to some author of many locales wants to be really
>    nasty, what is the worst they can do on the basis of this
>    contribution?
> 
> Thanks in advance for looking this over.
> 
> Sincerely,
> Jonathan
> 
> [1] http://bugs.debian.org/555168
> [2] http://www.helgefjell.de/debianitem.php?name=bug555168
> [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html

The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

--- Comment #24 from help at softwarefreedom dot org 2012-07-16 18:50:27 UTC ---
On 07/16/2012 04:55 AM, Keld Simonsen wrote:
> On Sun, Jul 15, 2012 at 08:13:31PM -0500, Jonathan Nieder wrote:
>> Hi Keld,
>>
>> Keld Simonsen wrote[1]:
>>
>>> Hmm, I contributed a number of locales. I always assumed that there was a
>>> copyright to each of them.
>>> I do hold a masters in legislate law.
>> [lots of helpful background snipped, including the intent of the
>> original notice]
>>
>> Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
>> automatically receive mails to that bug tracker.
>>
>> My guess is that the FSF's concerns that prompted the "this type of
>> thing isn't copyrightable" answer were USA-centric.  If I remember
>> correctly, in some jurisdictions outside the United States, the
>> eligibility of a work for copyright is based on the amount of work put
>> into it (as you remind me), while in the United States it's based on a
>> concept of creativity.
> 
> I claim that there is a lot of creativity in how the locales are written, at least
> the big ones.  As said one of my intial works were 100 pages of the POSIX.2 standard.
> And then the locales grew even further, with the advent of full ISO 10646 (Unicode)
> coverage and ISO TR 14652 extra categories.  There is a lot of design and ideas, 
> and a lot of design criteria in the locales. Including a number of theoretical landmarks,
> and something that could have been patentetd, if somebody were inclined to do such nasty things:-)
> And IMHO that has resulted in a system that still has a number of advantages over
> what big players in the market have done for i18n. 
> 
> And then there is compilation copyright according to the Berne convention - maybe you
> don't hold copyright on the data, but you hold copyright on the presentation on it and the
> collection of the combination of the data.
> 
> I would say in juridical terms it would not be safe to assume that there is no copyright on
> the locales (and charmaps and repertoiremaps).
> 
> Best regards
> keld


The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[help at softwarefreedom dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #23 from help at softwarefreedom dot org 2012-07-16 18:50:21 UTC ---
On 07/15/2012 03:04 PM, Jonathan Nieder wrote:
> Hi Eben et al,
> 
> Petr Baudis wrote:
> 
>> I'm sorry, I didn't realize the presence of this bug earlier. We have made some
>> research regarding this on the mailing list some time ago and this is currently
>> the opinion of FSF on the matter:
>>
>>   http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html
>>
>> I.e., locale data is not copyrightable, therefore it cannot be covered by any
>> licence and that is also the reason we do not require copyright assignment
>> paperwork from the locale authors.
>>
>> If you (e.g. Debian project) disagree, I encourage you to contact
>> copyright-clerk@fsf.org or SFLC for further discussions. For us developers,
>> this situation really is the best outcome since no paperwork is needed, I'd
>> say. My opinion is that the outcome of this bug should be removal of licence
>> notices (and "copyright" notices) from all localedata files to clear up any
>> possible confusion - comments?
> 
> Legal question for you.
> 
> Along with everything else it contains, the GNU C library provides a
> collection of locale data.  Localedata files include basic information
> about how programs should interact with users in a particular area:
> currency symbols, paper size, which encoding to use for text files,
> translations for "yes" and "no", and other details like that.  You can
> find the glibc locales in the localedata/locales directory of glibc:
> 
>   http://sourceware.org/git/?p=glibc.git;a=tree;f=localedata/locales
> 
> For example, the English locale for the United States is available
> from the following address.
> 
>   http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=localedata/locales/en_US
> 
> Since this is mostly factual information without much creative
> content, no one paid much mind to its license.  Many locales permit
> use, distribution, and commercial use without permitting modification:
> 
> 	# Distribution and use is free, also for
> 	# commercial purposes.
> 
> Most notably, the POSIX locale contains that notice.  Some are more
> philosophical:
> 
> 	% Distribution and use is
> 
> Josh Triplett (cc-ed) noticed this in 2009 and reported it to the
> Debian project[1].
> 
> We are concerned that although these files do not contain much
> creative content, they do contain some, for example in their comments.
> We are generally not lawyers and do not know what does and doesn't
> fall under copyright protection in the United States and elsewhere.
> It is important for it to be very clear to both us and our users what
> their rights are.
> 
> Helge (cc-ed) has taken a survey of authors of locales with the notice
> that doesn't permit modification to find what license terms they
> intend.  Some findings:
> 
>  - many locale authors expected that, as part of glibc, these
>    would have the same license as glibc (LGPL-2.1+)
> 
>  - they did not intend to forbid modification, and the notice was
>    propagated from the POSIX locale by copy and paste.
> 
>  - when asked what terms they would like going forward for their work,
>    most prefer "public domain", followed by LGPL and GPL.
> 
> You can find a summary of Helge's efforts at [2], and the actual
> emails are at [1].
> 
> Unlike most of glibc, the FSF has not historically required copyright
> assignment for these files.  Independently of the above investigation,
> they were recently asked about and reaffirmed this position[3]:
> 
> 	Well that was fast. The SFLC said that this type of thing isn't copyrightable, and that 
> 	paperwork isn't really necessary. So we should be good to go. Thank you so much for all your 
> 	help.
> 
> Questions:
> 
>  - Some locales (namely km_KH, lo_LA, th_TH, and uk_UA) contain
>    copyright notices.  Are we legally permitted to remove the
>    notices or to change them to say "Authors: ..."?
> 
>  - Suppose I wanted to add the text "You may freely use, modify,
>    distribute, and relicense this file" to each of the locale data
>    files, to make it completely clear that users are free to
>    incorporate text from them into differently licensed works.  Would
>    that be legally permissible?  Would it be accurate?  Is there any
>    reason not to do it?
> 
>  - When locale authors have stated a preferred license, is there value
>    in documenting that, or would it be counterproductive?
> 
>  - If the legal heir to some author of many locales wants to be really
>    nasty, what is the worst they can do on the basis of this
>    contribution?
> 
> Thanks in advance for looking this over.
> 
> Sincerely,
> Jonathan
> 
> [1] http://bugs.debian.org/555168
> [2] http://www.helgefjell.de/debianitem.php?name=bug555168
> [3] http://sourceware.org/ml/libc-locales/2012-q2/msg00136.html

The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

--- Comment #24 from help at softwarefreedom dot org 2012-07-16 18:50:27 UTC ---
On 07/16/2012 04:55 AM, Keld Simonsen wrote:
> On Sun, Jul 15, 2012 at 08:13:31PM -0500, Jonathan Nieder wrote:
>> Hi Keld,
>>
>> Keld Simonsen wrote[1]:
>>
>>> Hmm, I contributed a number of locales. I always assumed that there was a
>>> copyright to each of them.
>>> I do hold a masters in legislate law.
>> [lots of helpful background snipped, including the intent of the
>> original notice]
>>
>> Thanks much for this.  I'm cc-ing the SFLC since I'm not sure they
>> automatically receive mails to that bug tracker.
>>
>> My guess is that the FSF's concerns that prompted the "this type of
>> thing isn't copyrightable" answer were USA-centric.  If I remember
>> correctly, in some jurisdictions outside the United States, the
>> eligibility of a work for copyright is based on the amount of work put
>> into it (as you remind me), while in the United States it's based on a
>> concept of creativity.
> 
> I claim that there is a lot of creativity in how the locales are written, at least
> the big ones.  As said one of my intial works were 100 pages of the POSIX.2 standard.
> And then the locales grew even further, with the advent of full ISO 10646 (Unicode)
> coverage and ISO TR 14652 extra categories.  There is a lot of design and ideas, 
> and a lot of design criteria in the locales. Including a number of theoretical landmarks,
> and something that could have been patentetd, if somebody were inclined to do such nasty things:-)
> And IMHO that has resulted in a system that still has a number of advantages over
> what big players in the market have done for i18n. 
> 
> And then there is compilation copyright according to the Berne convention - maybe you
> don't hold copyright on the data, but you hold copyright on the presentation on it and the
> collection of the combination of the data.
> 
> I would say in juridical terms it would not be safe to assume that there is no copyright on
> the locales (and charmaps and repertoiremaps).
> 
> Best regards
> keld


The Software Freedom Law Center has received an email from you sent to
help@softwarefreedom.org.  We look forward to helping you in any way we
can, but before we can do that we need to make sure that you understand
that your email to us does not create an attorney-client relationship
with us and any information you send us will not be considered
confidential or privileged.  If you understand that, just reply to this
message by keeping the text of this paragraph and adding "Understood"
and we will respond to your email shortly.  However, if your message
contains any information that you would like to be considered
confidential or privileged (in other words, you do not want it to be
considered public information), please respond to this message with
"Delete my message" or just "Delete."  We understand that this procedure
may seem burdensome, but it is required by law in order to ensure your
rights and the rights of our clients are protected.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[jrnieder at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #26 from Jonathan Nieder <jrnieder at gmail dot com> 2012-07-17 15:07:41 UTC ---
(In reply to comment #17)
> (Anyhow, I'm not a lawyer so this is an argument I don't want to get into. I'm
> looking to a statement from someone at FSF/SFLC.)

I've asked the Debian Project Leader to make a formal request for advice,
since that seems to be how the SFLC would prefer this to go.  Bureaucracy...

Oh well.  I look forward to hints from the legal folk, too.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[cjlhomeaddress at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #27 from Chris Leonard <cjlhomeaddress at gmail dot com> 2012-07-25 17:50:11 UTC ---
I've had the opportunity to bring this to the attention of the GNOME Technical
Advisory Board (via a member I know).  I do think this is a serious matter and
requires high-level attention to drive resolution as quickly as feasible.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/11213] localedata licencing issues

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11213

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/11213] localedata: add copyright disclaimer to locale files

[vapier at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11213

Mike Frysinger <vapier at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|localedata licencing issues |localedata: add copyright
                   |                            |disclaimer to locale files
           Severity|critical                    |enhancement

--- Comment #28 from Mike Frysinger <vapier at gentoo dot org> ---
this is the FSF decision:
https://sourceware.org/ml/libc-locales/2013-q1/msg00048.html

we will be updating the locale data files with that header

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/11213] localedata: add copyright disclaimer to locale files

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #30 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  a4cea54b12ff33e81be4413abb74905020890330 (commit)
      from  f9378ac3773ffe998a2b3406568778ee9f77f759 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a4cea54b12ff33e81be4413abb74905020890330

commit a4cea54b12ff33e81be4413abb74905020890330
Author: Mike Frysinger <vapier@gentoo.org>
Date:   Sat Feb 20 01:59:46 2016 -0500

    localedata: standardize copyright/license information [BZ #11213]

    Use the language from the FSF in all locale files to disclaim any
    license/copyright on locale data.

    See https://sourceware.org/ml/libc-locales/2013-q1/msg00048.html

-----------------------------------------------------------------------

Summary of changes:
 localedata/ChangeLog                     |  331 ++++++++++++++++++++++++++++++
 localedata/locales/POSIX                 |    9 +-
 localedata/locales/aa_DJ                 |    7 +
 localedata/locales/aa_ER                 |    7 +
 localedata/locales/aa_ER@saaho           |    7 +
 localedata/locales/aa_ET                 |    7 +
 localedata/locales/af_ZA                 |    7 +
 localedata/locales/ak_GH                 |   16 +-
 localedata/locales/am_ET                 |    7 +
 localedata/locales/an_ES                 |    7 +
 localedata/locales/anp_IN                |   14 +-
 localedata/locales/ar_AE                 |    7 +
 localedata/locales/ar_BH                 |    7 +
 localedata/locales/ar_DZ                 |    7 +
 localedata/locales/ar_EG                 |    7 +
 localedata/locales/ar_IN                 |    7 +
 localedata/locales/ar_IQ                 |    7 +
 localedata/locales/ar_JO                 |    7 +
 localedata/locales/ar_KW                 |    7 +
 localedata/locales/ar_LB                 |    7 +
 localedata/locales/ar_LY                 |    7 +
 localedata/locales/ar_MA                 |    7 +
 localedata/locales/ar_OM                 |    7 +
 localedata/locales/ar_QA                 |    7 +
 localedata/locales/ar_SA                 |    7 +
 localedata/locales/ar_SD                 |   14 +-
 localedata/locales/ar_SS                 |   14 +-
 localedata/locales/ar_SY                 |    7 +
 localedata/locales/ar_TN                 |    7 +
 localedata/locales/ar_YE                 |    7 +
 localedata/locales/as_IN                 |    7 +
 localedata/locales/ast_ES                |    7 +
 localedata/locales/ayc_PE                |   14 +-
 localedata/locales/az_AZ                 |    9 +-
 localedata/locales/be_BY                 |    9 +-
 localedata/locales/be_BY@latin           |    9 +-
 localedata/locales/bem_ZM                |    9 +-
 localedata/locales/ber_DZ                |    9 +-
 localedata/locales/ber_MA                |    9 +-
 localedata/locales/bg_BG                 |    8 +-
 localedata/locales/bhb_IN                |    7 +
 localedata/locales/bho_IN                |    7 +
 localedata/locales/bn_BD                 |    7 +
 localedata/locales/bn_IN                 |    7 +
 localedata/locales/bo_CN                 |    7 +
 localedata/locales/bo_IN                 |    7 +
 localedata/locales/br_FR                 |    9 +-
 localedata/locales/br_FR@euro            |    9 +-
 localedata/locales/brx_IN                |    7 +
 localedata/locales/bs_BA                 |    9 +-
 localedata/locales/byn_ER                |    7 +
 localedata/locales/ca_AD                 |    9 +-
 localedata/locales/ca_ES                 |    9 +-
 localedata/locales/ca_ES@euro            |    9 +-
 localedata/locales/ca_FR                 |    9 +-
 localedata/locales/ca_IT                 |    9 +-
 localedata/locales/ce_RU                 |    7 +
 localedata/locales/cmn_TW                |   14 +-
 localedata/locales/crh_UA                |    9 +-
 localedata/locales/cs_CZ                 |    8 +-
 localedata/locales/csb_PL                |    9 +-
 localedata/locales/cv_RU                 |    9 +-
 localedata/locales/cy_GB                 |    8 +-
 localedata/locales/da_DK                 |    9 +-
 localedata/locales/de_AT                 |    9 +-
 localedata/locales/de_AT@euro            |    9 +-
 localedata/locales/de_BE                 |    9 +-
 localedata/locales/de_BE@euro            |    9 +-
 localedata/locales/de_CH                 |    9 +-
 localedata/locales/de_DE                 |    7 +
 localedata/locales/de_DE@euro            |    7 +
 localedata/locales/de_LU                 |    9 +-
 localedata/locales/de_LU@euro            |    9 +-
 localedata/locales/doi_IN                |    7 +
 localedata/locales/dv_MV                 |    9 +-
 localedata/locales/dz_BT                 |    7 +
 localedata/locales/el_CY                 |    7 +
 localedata/locales/el_GR                 |    9 +-
 localedata/locales/el_GR@euro            |    7 +
 localedata/locales/en_AG                 |    7 +
 localedata/locales/en_AU                 |    9 +-
 localedata/locales/en_BW                 |    9 +-
 localedata/locales/en_CA                 |    9 +-
 localedata/locales/en_DK                 |    9 +-
 localedata/locales/en_GB                 |    9 +-
 localedata/locales/en_HK                 |    7 +
 localedata/locales/en_IE                 |    9 +-
 localedata/locales/en_IE@euro            |    9 +-
 localedata/locales/en_IN                 |    7 +
 localedata/locales/en_NG                 |    9 +-
 localedata/locales/en_NZ                 |    9 +-
 localedata/locales/en_PH                 |    7 +
 localedata/locales/en_SG                 |    7 +
 localedata/locales/en_US                 |    7 +
 localedata/locales/en_ZA                 |    9 +-
 localedata/locales/en_ZM                 |    9 +-
 localedata/locales/en_ZW                 |    9 +-
 localedata/locales/es_AR                 |    9 +-
 localedata/locales/es_BO                 |    9 +-
 localedata/locales/es_CL                 |    9 +-
 localedata/locales/es_CO                 |    9 +-
 localedata/locales/es_CR                 |    9 +-
 localedata/locales/es_CU                 |    9 +-
 localedata/locales/es_DO                 |    9 +-
 localedata/locales/es_EC                 |    9 +-
 localedata/locales/es_ES                 |    9 +-
 localedata/locales/es_ES@euro            |    9 +-
 localedata/locales/es_GT                 |    9 +-
 localedata/locales/es_HN                 |    9 +-
 localedata/locales/es_MX                 |    9 +-
 localedata/locales/es_NI                 |    9 +-
 localedata/locales/es_PA                 |    9 +-
 localedata/locales/es_PE                 |    9 +-
 localedata/locales/es_PR                 |    9 +-
 localedata/locales/es_PY                 |    9 +-
 localedata/locales/es_SV                 |    9 +-
 localedata/locales/es_US                 |    9 +-
 localedata/locales/es_UY                 |    9 +-
 localedata/locales/es_VE                 |    9 +-
 localedata/locales/et_EE                 |    9 +-
 localedata/locales/eu_ES                 |    9 +-
 localedata/locales/eu_ES@euro            |    9 +-
 localedata/locales/fa_IR                 |    9 +-
 localedata/locales/ff_SN                 |    9 +-
 localedata/locales/fi_FI                 |    9 +-
 localedata/locales/fi_FI@euro            |    9 +-
 localedata/locales/fil_PH                |    9 +-
 localedata/locales/fo_FO                 |    9 +-
 localedata/locales/fr_BE                 |    9 +-
 localedata/locales/fr_BE@euro            |    9 +-
 localedata/locales/fr_CA                 |    9 +-
 localedata/locales/fr_CH                 |    9 +-
 localedata/locales/fr_FR                 |   10 +-
 localedata/locales/fr_FR@euro            |    9 +-
 localedata/locales/fr_LU                 |    9 +-
 localedata/locales/fr_LU@euro            |    9 +-
 localedata/locales/fur_IT                |    9 +-
 localedata/locales/fy_DE                 |    8 +-
 localedata/locales/fy_NL                 |    9 +-
 localedata/locales/ga_IE                 |    9 +-
 localedata/locales/ga_IE@euro            |    9 +-
 localedata/locales/gd_GB                 |   14 +-
 localedata/locales/gez_ER                |    7 +
 localedata/locales/gez_ER@abegede        |    7 +
 localedata/locales/gez_ET                |    7 +
 localedata/locales/gez_ET@abegede        |    7 +
 localedata/locales/gl_ES                 |    9 +-
 localedata/locales/gl_ES@euro            |    9 +-
 localedata/locales/gu_IN                 |    7 +
 localedata/locales/gv_GB                 |    9 +-
 localedata/locales/ha_NG                 |    9 +-
 localedata/locales/hak_TW                |   14 +-
 localedata/locales/he_IL                 |    9 +-
 localedata/locales/hi_IN                 |    7 +
 localedata/locales/hne_IN                |    7 +
 localedata/locales/hr_HR                 |    9 +-
 localedata/locales/hsb_DE                |    9 +-
 localedata/locales/ht_HT                 |   16 +-
 localedata/locales/hu_HU                 |    9 +-
 localedata/locales/hy_AM                 |    8 +-
 localedata/locales/i18n                  |    7 +
 localedata/locales/ia_FR                 |    7 +
 localedata/locales/id_ID                 |    9 +-
 localedata/locales/ig_NG                 |    9 +-
 localedata/locales/ik_CA                 |    9 +-
 localedata/locales/is_IS                 |    9 +-
 localedata/locales/iso14651_t1           |    7 +
 localedata/locales/iso14651_t1_common    |    7 +
 localedata/locales/iso14651_t1_pinyin    |    7 +
 localedata/locales/it_CH                 |    9 +-
 localedata/locales/it_IT                 |    9 +-
 localedata/locales/it_IT@euro            |    9 +-
 localedata/locales/iu_CA                 |    8 +-
 localedata/locales/iw_IL                 |    9 +-
 localedata/locales/ja_JP                 |    7 +
 localedata/locales/ka_GE                 |    8 +-
 localedata/locales/kk_KZ                 |    9 +-
 localedata/locales/kl_GL                 |    9 +-
 localedata/locales/km_KH                 |   32 +---
 localedata/locales/kn_IN                 |    7 +
 localedata/locales/ko_KR                 |    8 +-
 localedata/locales/kok_IN                |    7 +
 localedata/locales/ks_IN                 |    7 +
 localedata/locales/ks_IN@devanagari      |    7 +
 localedata/locales/ku_TR                 |    9 +-
 localedata/locales/kw_GB                 |    9 +-
 localedata/locales/ky_KG                 |    7 +
 localedata/locales/lb_LU                 |    7 +
 localedata/locales/lg_UG                 |    9 +-
 localedata/locales/li_BE                 |    7 +-
 localedata/locales/li_NL                 |    7 +-
 localedata/locales/lij_IT                |    7 +
 localedata/locales/lo_LA                 |   35 +---
 localedata/locales/lt_LT                 |    9 +-
 localedata/locales/lv_LV                 |    9 +-
 localedata/locales/lzh_TW                |   14 +-
 localedata/locales/mag_IN                |    7 +
 localedata/locales/mai_IN                |    7 +
 localedata/locales/mg_MG                 |    9 +-
 localedata/locales/mhr_RU                |    9 +-
 localedata/locales/mi_NZ                 |    9 +-
 localedata/locales/mk_MK                 |    9 +-
 localedata/locales/ml_IN                 |    7 +
 localedata/locales/mn_MN                 |    9 +-
 localedata/locales/mni_IN                |    7 +
 localedata/locales/mr_IN                 |    7 +
 localedata/locales/ms_MY                 |    7 +
 localedata/locales/mt_MT                 |    7 +
 localedata/locales/my_MM                 |    7 +
 localedata/locales/nan_TW                |   14 +-
 localedata/locales/nan_TW@latin          |    9 +-
 localedata/locales/nb_NO                 |    9 +-
 localedata/locales/nds_DE                |    7 +-
 localedata/locales/nds_NL                |    7 +-
 localedata/locales/ne_NP                 |    7 +
 localedata/locales/nhn_MX                |    7 +
 localedata/locales/niu_NU                |    7 +
 localedata/locales/niu_NZ                |    7 +
 localedata/locales/nl_AW                 |    7 +
 localedata/locales/nl_BE                 |    9 +-
 localedata/locales/nl_BE@euro            |    9 +-
 localedata/locales/nl_NL                 |    9 +-
 localedata/locales/nl_NL@euro            |    9 +-
 localedata/locales/nn_NO                 |    7 +
 localedata/locales/nr_ZA                 |    7 +
 localedata/locales/nso_ZA                |    7 +
 localedata/locales/oc_FR                 |    8 +-
 localedata/locales/om_ET                 |    7 +
 localedata/locales/om_KE                 |    7 +
 localedata/locales/or_IN                 |    7 +
 localedata/locales/os_RU                 |    9 +-
 localedata/locales/pa_IN                 |    7 +
 localedata/locales/pa_PK                 |    9 +-
 localedata/locales/pap_AW                |   14 +-
 localedata/locales/pap_CW                |   14 +-
 localedata/locales/pl_PL                 |    9 +-
 localedata/locales/ps_AF                 |    7 +
 localedata/locales/pt_BR                 |    9 +-
 localedata/locales/pt_PT                 |    9 +-
 localedata/locales/pt_PT@euro            |    9 +-
 localedata/locales/quz_PE                |   17 +-
 localedata/locales/raj_IN                |    7 +
 localedata/locales/ro_RO                 |    9 +-
 localedata/locales/ru_RU                 |    9 +-
 localedata/locales/ru_UA                 |    9 +-
 localedata/locales/rw_RW                 |    7 +
 localedata/locales/sa_IN                 |    7 +
 localedata/locales/sat_IN                |    7 +
 localedata/locales/sc_IT                 |    9 +-
 localedata/locales/sd_IN                 |    7 +
 localedata/locales/sd_IN@devanagari      |    7 +
 localedata/locales/se_NO                 |    9 +-
 localedata/locales/shs_CA                |    9 +-
 localedata/locales/si_LK                 |    7 +
 localedata/locales/sid_ET                |    7 +
 localedata/locales/sk_SK                 |    8 +-
 localedata/locales/sl_SI                 |    9 +-
 localedata/locales/so_DJ                 |    7 +
 localedata/locales/so_ET                 |    7 +
 localedata/locales/so_KE                 |    7 +
 localedata/locales/so_SO                 |    7 +
 localedata/locales/sq_AL                 |    7 +
 localedata/locales/sq_MK                 |    7 +
 localedata/locales/sr_ME                 |    9 +-
 localedata/locales/sr_RS                 |   10 +-
 localedata/locales/sr_RS@latin           |   10 +-
 localedata/locales/ss_ZA                 |    7 +
 localedata/locales/st_ZA                 |    7 +
 localedata/locales/sv_FI                 |    9 +-
 localedata/locales/sv_FI@euro            |    9 +-
 localedata/locales/sv_SE                 |    9 +-
 localedata/locales/sw_KE                 |    9 +-
 localedata/locales/sw_TZ                 |    9 +-
 localedata/locales/szl_PL                |    9 +-
 localedata/locales/ta_IN                 |    7 +
 localedata/locales/ta_LK                 |    9 +-
 localedata/locales/tcy_IN                |    7 +
 localedata/locales/te_IN                 |    7 +
 localedata/locales/tg_TJ                 |    9 +-
 localedata/locales/th_TH                 |   31 +---
 localedata/locales/the_NP                |   18 +-
 localedata/locales/ti_ER                 |    7 +
 localedata/locales/ti_ET                 |    7 +
 localedata/locales/tig_ER                |    7 +
 localedata/locales/tk_TM                 |   10 +-
 localedata/locales/tl_PH                 |    9 +-
 localedata/locales/tn_ZA                 |    7 +
 localedata/locales/tr_CY                 |    9 +-
 localedata/locales/tr_TR                 |    9 +-
 localedata/locales/translit_circle       |    7 +
 localedata/locales/translit_cjk_compat   |    7 +
 localedata/locales/translit_cjk_variants |    7 +
 localedata/locales/translit_combining    |    7 +
 localedata/locales/translit_compat       |    7 +
 localedata/locales/translit_font         |    7 +
 localedata/locales/translit_fraction     |    7 +
 localedata/locales/translit_hangul       |    7 +
 localedata/locales/translit_narrow       |    7 +
 localedata/locales/translit_neutral      |    7 +
 localedata/locales/translit_small        |    7 +
 localedata/locales/translit_wide         |    7 +
 localedata/locales/ts_ZA                 |    7 +
 localedata/locales/tt_RU                 |    9 +-
 localedata/locales/tt_RU@iqtelif         |    9 +-
 localedata/locales/ug_CN                 |    9 +-
 localedata/locales/uk_UA                 |   12 +-
 localedata/locales/unm_US                |    9 +-
 localedata/locales/ur_IN                 |    7 +
 localedata/locales/ur_PK                 |    9 +-
 localedata/locales/uz_UZ                 |    9 +-
 localedata/locales/uz_UZ@cyrillic        |    9 +-
 localedata/locales/ve_ZA                 |    7 +
 localedata/locales/vi_VN                 |    9 +-
 localedata/locales/wa_BE                 |    8 +-
 localedata/locales/wa_BE@euro            |    9 +-
 localedata/locales/wae_CH                |    7 +
 localedata/locales/wal_ET                |    7 +
 localedata/locales/wo_SN                 |    9 +-
 localedata/locales/xh_ZA                 |    7 +
 localedata/locales/yi_US                 |    8 +-
 localedata/locales/yo_NG                 |    9 +-
 localedata/locales/yue_HK                |    7 +
 localedata/locales/zh_CN                 |    7 +
 localedata/locales/zh_HK                 |    7 +
 localedata/locales/zh_SG                 |    7 +
 localedata/locales/zh_TW                 |    7 +
 localedata/locales/zu_ZA                 |    7 +
 327 files changed, 2610 insertions(+), 529 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/11213] localedata: add copyright disclaimer to locale files

[vapier at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11213

Mike Frysinger <vapier at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.24

--- Comment #29 from Mike Frysinger <vapier at gentoo dot org> ---
all localedata files now contain that language

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug localedata/11213] localedata: add copyright disclaimer to locale files

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11213

--- Comment #31 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The annotated tag, glibc-2.24 has been created
        at  beb0f59498c3e0337df298f9d7a3f8f77eb39842 (tag)
   tagging  fdfc9260b61d3d72541f18104d24c7bcb0ce5ca2 (commit)
  replaces  glibc-2.23
 tagged by  Carlos O'Donell
        on  Mon Aug 1 22:46:26 2016 -0400

- Log -----------------------------------------------------------------
The GNU C Library
=================

The GNU C Library version 2.24 is now available.

The GNU C Library is used as *the* C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library.  It follows all relevant
standards including ISO C11 and POSIX.1-2008.  It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library webpage is at http://www.gnu.org/software/libc/

Packages for the 2.24 release may be downloaded from:
        http://ftpmirror.gnu.org/libc/
        http://ftp.gnu.org/gnu/libc/

The mirror list is at http://www.gnu.org/order/ftp.html

NEWS for version 2.24
=====================

* The minimum Linux kernel version that this version of the GNU C Library
  can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
  kernel version 2.6.32 or later suffices (on architectures that already
  required kernel versions more recent than 3.2, those requirements remain
  unchanged).  Linux 3.2 or later kernel headers are required on all
  architectures.

* The pap_AN locale has been deleted.  This has been deprecated for a long
  time.  It has been replaced by pap_AW & pap_CW, both of which have long
  been included in previous releases.

* The readdir_r and readdir64_r functions have been deprecated.  It is
  recommended to use readdir and readdir64 instead.

* The type “union wait” has been removed.  It was deprecated in the early
  1990s and never part of POSIX.  Application code should use the int type
  instead of “union wait”.

* A new NSS action is added to facilitate large distributed system
  administration.  The action, MERGE, allows remote user stores like LDAP
  to be merged into local user stores like /etc/groups in order to provide
  easy to use, updated, and managed sets of merged credentials.  The new
  action can be used by configuring it in /etc/nsswitch.conf:
  group: files [SUCCESS=merge] nis
  Implemented by Stephen Gallagher (Red Hat).

* The deprecated __malloc_initialize_hook variable has been removed from the
  API.

* The long unused localedef --old-style option has been removed.  It hasn't
  done anything in over 16 years.  Scripts using this option can safely
  drop it.

* nextupl, nextup, nextupf, nextdownl, nextdown and nextdownf are added to
  libm.  They are defined by TS 18661 and IEEE754-2008.  The nextup functions
  return the next representable value in the direction of positive infinity
  and the nextdown functions return the next representable value in the
  direction of negative infinity.  These are currently enabled as GNU
  extensions.

Security related changes:

* An unnecessary stack copy in _nss_dns_getnetbyname_r was removed.  It
  could result in a stack overflow when getnetbyname was called with an
  overly long name.  (CVE-2016-3075)

* Previously, getaddrinfo copied large amounts of address data to the stack,
  even after the fix for CVE-2013-4458 has been applied, potentially
  resulting in a stack overflow.  getaddrinfo now uses a heap allocation
  instead.  Reported by Michael Petlan.  (CVE-2016-3706)

* The glob function suffered from a stack-based buffer overflow when it was
  called with the GLOB_ALTDIRFUNC flag and encountered a long file name.
  Reported by Alexander Cherepanov.  (CVE-2016-1234)

* The Sun RPC UDP client could exhaust all available stack space when
  flooded with crafted ICMP and UDP messages.  Reported by Aldy Hernandez'
  alloca plugin for GCC.  (CVE-2016-4429)

* The IPv6 name server management code in libresolv could result in a memory
  leak for each thread which is created, performs a failing naming lookup,
  and exits.  Over time, this could result in a denial of service due to
  memory exhaustion.  Reported by Matthias Schiffer.  (CVE-2016-5417)

The following bugs are resolved with this release:

  [1170] localedata: ne_NP: update Nepali locale definition file
  [3629] manual: stpcpy description in string.texi refers to MS-DOG instead
    of MS-DOS.
  [6527] malloc: [powerpc] Malloc alignment insufficient for PowerPC
  [6796] math: fdim() does not set errno on overflow
  [10354] libc: posix_spawn should use vfork() in more cases than presently
  [11213] localedata: localedata: add copyright disclaimer to locale files
  [12143] localedata: chr_US: new Cherokee locale
  [12450] localedata: sgs_LT: new locale
  [12676] localedata: ln_CD: new locale
  [13237] localedata: LC_ADDRESS.country_name: update all locales w/latest
    CLDR data
  [13304] math: fma, fmaf, fmal produce wrong results
  [14259] build: --localedir arg to configure is ignored
  [14499] nptl: Does posix_spawn invoke atfork handlers / use vfork?
  [14750] libc: Race condition in posix_spawn vfork usage vs signal handlers
  [14934] localedata: es_CL: wrong first weekday chilean locale
  [15262] localedata: LC_MESSAGES.yesexpr/noexpr: inconsistent use of
    romanisation
  [15263] localedata: LC_MESSAGES.yesexpr/noexpr: inconsistent use of 1/0
    and +/-
  [15264] localedata: LC_MESSAGES.yesstr/nostr: lacking in many locales
  [15368] nptl: raise() is not async-signal-safe
  [15479] math: ceil, floor, round and trunc raise inexact exception
  [15578] localedata: kk_KZ: various updates
  [16003] localedata: pap_AN: punt old locale
  [16137] localedata: iw_IL: punt old locale
  [16190] localedata: eo: new esperanto locale
  [16374] localedata: lv_LV: change currency symbol in LC_MONETARY to euro
  [16742] malloc: race condition: pthread_atfork() called before first
    malloc() results in unexpected locking behaviour/deadlocks
  [16975] localedata: LC_MESSAGES.yesexpr/noexpr: revisit capitalization in
    all locales
  [16983] localedata: postal_fmt does not allow %l and %n modifiers
  [17565] localedata: pt_PT: wrong (work-)week start
  [17899] math: [powerpc] floorl returns negative zero with FE_DOWNWARD
  [17950] build: Build fails with -msse
  [18205] localedata: be_BY*: wrong first_weekday and first_workday
  [18433] libc: posix_spawn does not return correctly upon failure to
    execute
  [18453] localedata: charmaps/IBM875: incorrect codes
  [18712] string: bits/string2.h incompatible with -O2 -Werror=packed
    -Wsystem-headers
  [18896] localedata: he_IL: improvements for currency
  [18911] localedata: ro_RO: Correcting week day name for "Tuesday" in
    Romanian locale data
  [18960] locale: s390: _nl_locale_subfreeres uses larl opcode on misaligned
    symbol
  [19056] libc: Deprecate readdir_r
  [19133] localedata: pt_*: days & months should be lowercase in Portuguese
    language
  [19198] localedata: nl_NL: small improvements for Dutch locales
  [19257] network: Per-thread memory leak in __res_vinit with IPv6
    nameservers (CVE-2016-5417)
  [19269] build: tst-audit4 and tst-audit10 failures with gcc-6 on non avx
    machine
  [19400] locale: Language missing in  "iso-639.def", trivial fix in
    description
  [19431] malloc: Deadlock between fflush, getdelim, and fork
  [19505] libc: Incorrect file descriptor validity checks in
    posix_spawn_file_actions_add{open,close,dup2}
  [19509] dynamic-link: dlsym, dlvsym do not report errors through dlerror
    when using RTLD_NEXT
  [19512] locale: Stale `#ifndef HAVE_BUILTIN_EXPECT' in
    `intl/{gettextP,loadinfo}.h'
  [19534] libc: execle, execlp may use malloc
  [19568] localedata: *_CH: Swiss locales have inconsistent start of week
  [19573] network: res_nclose and __res_maybe_init disagree about name
    server initialization, breaking Hesiod
  [19575] localedata: Status of GB18030 tables
  [19581] localedata: sr_* date_fmt string contains additional newline
  [19583] string: SSSE3_Fast_Copy_Backward flag needs to be enabled for AMD
    Excavator core
  [19592] math: [ldbl-128ibm] ceill incorrect in non-default rounding modes
  [19593] math: [ldbl-128ibm] truncl incorrect in non-default rounding modes
  [19594] math: [ldbl-128ibm] roundl incorrect in non-default rounding modes
  [19595] math: [ldbl-128ibm] fmodl incorrect for results in subnormal
    double range
  [19602] math: [ldbl-128ibm] fmodl handling of equal arguments with low
    part zero incorrect
  [19603] math: [ldbl-128ibm] remainderl, remquol incorrect sign handling in
    equality tests
  [19610] dynamic-link: ldconfig -X removes stale symbolic links
  [19613] libc: s390x (64 bit) macro expansion WCOREDUMP and others
  [19633] locale: strfmon_l applies global locale to number formatting
  [19642] network: Memory leak in getnameinfo
  [19648] libc: test-skeleton.c: Do not set RLIMIT_DATA
  [19653] libc: Potential for NULL pointer dereference (CWE-476) in
    glibc-2.22
  [19654] math: [x86_64] Need testcase for BZ #19590 fix
  [19671] localedata: Missing Sanity Check for malloc() in 'tst-fmon.c' &
    'tst-numeric.c'
  [19674] math: [ldbl-128ibm] powl incorrect overflow handling
  [19677] math: [ldbl-128ibm] remainderl equality test incorrect for zero
    low part
  [19678] math: [ldbl-128ibm] nextafterl, nexttowardl incorrect sign of zero
    result
  [19679] dynamic-link: gcc-4.9.3 C++ exception handling broken due to
    unaligned stack
  [19726] locale: Converting UCS4LE to INTERNAL with iconv() does not update
    pointers and lengths in error-case.
  [19727] locale: Converting from/to UTF-xx with iconv() does not always
    report errors on UTF-16 surrogates values.
  [19755] nscd: nscd assertion failure in gc
  [19758] dynamic-link: Typo in EXTRA_LD_ENVVARS for x86-64
  [19759] libc: mempcpy shouldn't be inlined
  [19762] dynamic-link: HAS_CPU_FEATURE/HAS_ARCH_FEATURE are easy to misuse
  [19765] libc: s390 needs an optimized mempcpy
  [19779] glob: glob: buffer overflow with GLOB_ALTDIRFUNC due to incorrect
    NAME_MAX limit assumption (CVE-2016-1234)
  [19783] build: benchtests don't support --enable-hardcoded-path-in-tests
  [19787] network: Missing and incorrect truncation checks in getnameinfo
  [19790] math: [ldbl-128ibm] nearbyintl incorrect in non-default rounding
    modes
  [19791] network: Assertion failure in res_query.c with un-connectable name
    server addresses
  [19792] libc: MIPS: backtrace yields infinite backtrace with makecontext
  [19822] math: libm.so install clobbers old version
  [19825] network: resolv: send_vc can return uninitialized data in second
    response to getaddrinfo
  [19830] network: nss_dns: should check RDATA length against buffer length
  [19831] network: nss_dns: getaddrinfo returns uninitialized data when
    confronted with A/AAAA records of invalid size
  [19837] nss: nss_db: No retries for some long lines with a larger buffer
  [19848] math: powl(10,n) for n=-4,-5,-6,-7 is off by more than 1 ULP
  [19853] stdio: Printing IBM long double in decimal with high precision is
    sometimes incorrect
  [19860] build: x86_64: compile errors for tst-audit10 and tst-auditmod10b
  [19861] nptl: libpthread IFUNC resolver for fork can lead to crash
  [19862] network: resolv, nss_dns: Remove remaining logging of unexpected
    record types
  [19865] network: Assertion failure or memory leak in
    _nss_dns_getcanonname_r
  [19868] network: nss_dns: netent code does not skip over non-PTR records
  [19879] network: nss_dns: Stack overflow in getnetbyname implementation
    (CVE-2016-3075)
  [19881] string: Improve x86-64 memset
  [19907] string: Incorrect memcpy tests
  [19916] dynamic-link: S390: fprs/vrs are not saved/restored while
    resolving symbols
  [19925] libc: termios.h XCASE namespace
  [19928] string: memmove-vec-unaligned-erms.S is slow with large data size
  [19929] libc: limits.h NL_NMAX namespace
  [19931] stdio: Memory leak in vfprintf
  [19957] libc: clone(CLONE_VM) access invalid parent memory
  [19963] localedata: en_IL: New locale
  [19989] stdio: stdio.h cuserid namespace
  [19994] network: getaddrinfo does not restore RES_USE_INET6 flag in
    gethosts
  [19996] locale: langinfo.h nl_langinfo_l namespace
  [20005] stdio: fflush on a file opened with fmemopen resets position to 0
  [20010] network: getaddrinfo: Stack overflow in hostent translation
    (CVE-2016-3706)
  [20012] stdio: libio: fmemopen append mode failure
  [20014] stdio: stdio.h namespace for pre-threads POSIX
  [20017] network: resolv: Use gmtime_r instead of gmtime in p_secstodate
  [20023] libc: fcntl.h timespec namespace
  [20024] math: [x86_64] vectorized sincos trashes the stack
  [20031] network: nss_hesiod: Heap overflow in get_txt_records
  [20041] time: sys/time.h timespec namespace
  [20043] libc: unistd.h missing cuserid for UNIX98 and before
  [20044] libc: unistd.h missing pthread_atfork for UNIX98
  [20051] libc: ttyslot in wrong header under wrong conditions
  [20054] libc: gethostname not declared for XPG4
  [20055] libc: termios.h missing tcgetsid for XPG4
  [20072] dynamic-link: x86 init_cpu_features is called twice in static
    executable
  [20073] libc: sys/stat.h fchmod namespace
  [20074] libc: stdlib.h rand_r namespace
  [20076] libc: sys/stat.h missing S_IFSOCK, S_ISSOCK for XPG4
  [20094] libc: stdlib.h should not declare grantpt, ptsname, unlockpt for
    XPG3
  [20111] libc: struct sockaddr_storage cannot be aggregate-copied
  [20112] network: sunrpc: stack (frame) overflow in Sun RPC clntudp_call
    (CVE-2016-4429)
  [20115] string: Extra alignment in memset-vec-unaligned-erms.S
  [20119] libc: Wrong mask for processors level type from CPUID
  [20139] dynamic-link: Upper part of zmm is zeroed if Glibc is built with
    AS not supporting AVX512
  [20151] math: [ldbl-128/ldbl-128ibm] j0l, j1l, y0l, y1l return sNaN for
    sNaN argument
  [20153] math: [ldbl-128ibm] sqrtl (sNaN) returns sNaN
  [20156] math: [ldbl-128ibm] ceill, rintl etc. return sNaN for sNaN
    argument
  [20157] math: [powerpc] fabsl (sNaN) wrongly raises "invalid"
  [20160] math: [powerpc] ceil, rint etc. return sNaN for sNaN input
  [20178] libc: posix_spawn{p} should not call exit
  [20191] stdio: libio: vtables hardening
  [20195] string: FMA4 detection requires CPUID execution with register
    eax=0x80000001
  [20198] libc: quick_exit incorrectly destroys C++11 thread objects.
  [20205] math: [i386/x86_64] nextafterl incorrect incrementing negative
    subnormals
  [20212] math: acos (sNaN) returns sNaN
  [20213] math: asin (sNaN) returns sNaN
  [20214] network: Linux header sync with linux/in6.h and ipv6.h again.
  [20218] math: [i386] asinhl (sNaN) returns sNaN
  [20219] math: [i386] atanhl (sNaN) returns sNaN
  [20222] stdio: fopencookie: Mangle function pointers
  [20224] math: [i386] cbrtl (sNaN) returns sNaN
  [20225] math: ldexp, scalbn, scalbln return sNaN for sNaN input
  [20226] math: [i386/x86_64] expl, exp10l, expm1l return sNaN for sNaN
    input
  [20227] math: [i386/x86_64] logl (sNaN) returns sNaN
  [20228] math: [i386/x86_64] log10l (sNaN) returns sNaN
  [20229] math: [i386/x86_64] log1pl (sNaN) returns sNaN
  [20232] math: [ldbl-128] expm1l (sNaN) returns sNaN
  [20233] math: [ldbl-128ibm] expm1l (sNaN) returns sNaN
  [20234] math: [ldbl-128ibm] log1pl (sNaN) returns sNaN
  [20235] math: [i386/x86_64] log2l (sNaN) returns sNaN
  [20237] nss: nss_db: get*ent segfaults without preceding set*ent
  [20240] math: modf (sNaN) returns sNaN
  [20248] libc: debug/tst-longjump_chk2 calls printf from a signal handler
  [20250] math: frexp (sNaN) returns sNaN
  [20252] math: atan2 (sNaN, qNaN) fails to raise "invalid"
  [20255] math: [i386] fdim, fdimf return with excess range and precision /
    double rounding
  [20256] math: [i386/x86_64] fdiml returns sNaN for sNaN input
  [20260] string: ../sysdeps/x86/bits/string.h:1092:3: error: array
    subscript is below array bounds [-Werror=array-bounds]
  [20262] nis: _nss_nis_initgroups_dyn always returns NSS_STATUS_NOTFOUND
  [20263] nptl: robust mutex deadlocks if other thread requests timedlock
    (Only arm/linux)
  [20277] libc: $dp is not initialized correctly in sysdeps/hppa/start.S
  [20284] malloc: malloc: Corrupt arena avoidance causes unnecessary mmap
    fallbacks
  [20296] math: [i386/x86_64] scalbl returns sNaN for sNaN input, missing
    "invalid" exceptions
  [20314] nptl: make[4]: *** [/usr/include/stdlib.h] Error 1
  [20316] localedata: id_ID: Februari instead of Pebruari
  [20327] string: POWER8 strcasecmp returns incorrect result
  [20347] math: Failure: Test: j0_downward (0xap+0)
  [20348] libc: FAIL: misc/tst-preadvwritev64
  [20349] libc: 64-bit value is passed differently in p{readv,writev}{64}
  [20350] libc: There is no test for p{read,write}64
  [20357] math: Incorrect cos result for 1.5174239687223976
  [20384] build: Don't run libmvec-sincos-avx* tests on non avx machines

Contributors
============

This release was made possible by the contributions of many people.
The maintainers are grateful to everyone who has contributed
changes or bug reports.  These include:

Adhemerval Zanella
Andreas Schwab
Andrew Senkevich
Anton Blanchard
Arnas Udovičius
Aurelien Jarno
Carlos Eduardo Seo
Carlos O'Donell
Chris Metcalf
Chung-Lin Tang
Claude Paroz
Dimitris Pappas
Dmitry V. Levin
Dylan Alex Simon
Eduardo Trápani
Florian Weimer
Gabriel F. T. Gomes
Gunnar Hjalmarsson
Gustavo Romero
Guy Rutenberg
H.J. Lu
Hongjiu Zhang
Jiyoung Yun
John David Anglin
Joseph Myers
Khem Raj
Maciej W. Rozycki
Mark Wielaard
Marko Myllynen
Martin Galvan
Matthew Fortune
Matthias Wallnoefer
Mike FABIAN
Mike Frysinger
Neskie Manuel
Nick Alcock
Paras pradhan
Paul E. Murphy
Paul Pluzhnikov
Rajalakshmi Srinivasaraghavan
Rical Jasan
Richard Henderson
Robin van der Vliet
Roland McGrath
Samuel Thibault
Siddhesh Poyarekar
Simion Onea
Stefan Liebler
Stephen Gallagher
Szabolcs Nagy
Timur Birsh
Torvald Riegel
Tulio Magno Quites Machado Filho
Wilco Dijkstra
Will Newton
Yvan Roux
Zack Weinberg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXoAmUAAoJEBZ5K06iU0D4Nx8P/3EGutqtVg6OubIKw9izzWMO
6pNj7Iy569Bk+ER2ElR5xvTeumpVS05A8r94oXX0rzCNsFIAVct7Ocr62r/OQz8A
+p6W+USpORha6m+SzY1bkI1109RR6Q4jpbENkhk/JKcBXJ7AHWHeW72QKMP0+JJu
QBavQ8b3ZLJQ4X+Be10bjseTaqAn4XNYj6fmajQC2x7F0sL32+xFjSktw8hn9AFs
A32yS3c2v/GfqKIyNj4Yz/akZzffACZ+8twVkJGDK5eoMGGQ/Obr3yttzKSNsN+O
n73HyyP4O8dG/U+v5k0IR4drT6mnUFRHUvkN10VahCHiTSG5AFQut30lwvVKzhF6
VYylPzbhOcVnSuJqdT4xJ6sumvQl5W4IAb/GKSso62MrcKFYPFdnx0wgMX6Arlgm
wkuSkSQCOfj/be2/R88alRJYNTW39vsPqKPop5ov/uXbfHqIoFcQitS0vDFJqGIC
zOhJSlV0cS/StKkw0xNgQ6Ay/dnHMm2Hzg5lqRzaQblkDVrNfN7TqyeZBEhwh3N5
KifvkdKSO6L6N7dM3nLsT+qJWoSp8dNsQ+qCHL6A/hL0SA4nxJ3hmC5hanCL+7D8
MrO5m+Z5yjpdSWFDmJv2LZsIzYX2UGZmUO19c7zvZoIrXuJE4bQXEmM4rylrNXGS
Lcke/0PPdvDeSW7iWjjP
=j7Oo
-----END PGP SIGNATURE-----

Adhemerval Zanella (40):
      Open development for 2.24.
      Updated translations for 2.23.
      Regenerate libc.pot for 2.23.
      Regenerated configure scripts.
      Update NEWS with 2.24 template
      posix: Remove dynamic memory allocation from execl{e,p}
      posix: execvpe cleanup
      posix: New Linux posix_spawn{p} implementation
      posix: Fix tst-execvpe5 for --enable-hardcoded-path-in-tests
      posix: Fix posix_spawn invalid memory access
      posix: Fix posix_spawn implict check style
      Fix tst-dlsym-error build
      Improve generic strspn performance
      Improve generic strpbrk performance
      Remove powerpc64 strspn, strcspn, and strpbrk implementation
      Use PTR_ALIGN_DOWN on strcspn and strspn
      Define __ASSUME_ALIGNED_REGISTER_PAIRS for missing ports
      Consolidate off_t/off64_t syscall argument passing
      Consolidate pread/pread64 implementations
      Consolidate pwrite/pwrite64 implementations
      Fix pread consolidation on ports that require argument alignment
      libio: Update internal fmemopen position after write (BZ #20005)
      Fix clone (CLONE_VM) pid/tid reset (BZ#19957)
      libio: Fix fmemopen append mode failure (BZ# 20012)
      powerpc: Fix clone CLONE_VM compare
      Adjust kernel-features.h defaults for recvmsg and sendmsg
      network: recvmsg and sendmsg standard compliance (BZ#16919)
      network: recvmmsg and sendmmsg standard compliance (BZ#16919)
      network: Fix missing bits from {recv,send}{m}msg standard com,pliance
      posix: Call _exit in failure case for posix_spawn{p} (BZ#20178)
      Consolidate preadv/preadv64 implementation
      Consolidate pwritev/pwritev64 implementations
      Revert {send,sendm,recv,recvm}msg conformance changes
      Remove __ASSUME_FUTEX_LOCK_PI
      nptl: Add sendmmsg and recvmmsg cancellation tests
      Fix p{readv,writev}{64} consolidation implementation
      nptl: Add more coverage in tst-cancel4
      Remove __ASSUME_OFF_DIFF_OFF64 definition
      Fix LO_HI_LONG definition
      Refactor Linux raise implementation (BZ#15368)

Andreas Schwab (13):
      Don't use long double math functions if NO_LONG_DOUBLE
      Fix min/max needed for ascii to INTERNAL conversion
      Fix compilation of test-signgam-* tests
      Fix resource leak in resolver (bug 19257)
      Register extra test objects
      m68k: avoid local labels in symbol table
      m68k: use large PIC model for gcrt1.o
      Use __typeof instead of typeof
      Fix nscd assertion failure in gc (bug 19755)
      Avoid array-bounds warning for strncat on i586 (bug 20260)
      Return proper status from _nss_nis_initgroups_dyn (bug 20262)
      m68k: suppress -Wframe-address warning
      Add test case for bug 20263

Andrew Senkevich (2):
      Added tests to ensure linkage through libmvec *_finite aliases which are
      Fixed wrong vector sincos/sincosf ABI to have it compatible with

Anton Blanchard (1):
      powerpc: Add a POWER8-optimized version of sinf()

Arnas Udovičius (1):
      localedata: sgs_LT: new locale [BZ #12450]

Aurelien Jarno (17):
      Add placeholder libnsl.abilist and libutil.abilist files
      Add sys/auxv.h wrapper to include/sys/
      mips: terminate the FDE before the return trampoline in makecontext
      Assume __NR_openat is always defined
      Assume __NR_utimensat is always defined
      Synchronize <sys/personality.h> with kernel headers
      MIPS, SPARC: fix wrong vfork aliases in libpthread.so
      MIPS, SPARC: more fixes to the vfork aliases in libpthread.so
      MIPS: run tst-mode-switch-{1,2,3}.c using test-skeleton.c
      i686/multiarch: Regenerate ulps
      SPARC64: update localplt.data
      SPARC: fix nearbyint on sNaN input
      New locale de_LI
      localedata: fix de_LI locale
      ppc: Fix modf (sNaN) for pre-POWER5+ CPU (bug 20240).
      Define __USE_KERNEL_IPV6_DEFS macro for non-Linux kernels
      sparc: remove ceil, floor, trunc sparc specific implementations

Carlos Eduardo Seo (2):
      powerpc: Fix dl-procinfo HWCAP
      powerpc: Optimization for strlen for POWER8.

Carlos O'Donell (16):
      nptl: support thread stacks that grow up
      GB 18030-2005: Document non-rountrip and PUA mappings (bug 19575).
      Enable --localedir to set message catalog directory (Bug 14259)
      NEWS (2.23): Fix typo in bug 19048 text.
      Removed unused timezone/checktab.awk.
      Remove mention of checktab.awk in timezone/README.
      Fix building glibc master with NDEBUG and --with-cpu.
      localedata: an_ES: fix case of lang_ab
      Fix macro API for __USE_KERNEL_IPV6_DEFS.
      Fix include/wchar.h for C++
      Bug 20198: quick_exit should not call destructors.
      Bug 20214: Fix linux/in6.h and netinet/in.h sync.
      Bug 20215: Always undefine __always_inline before defining it.
      Expand comments in Linux times() implementation.
      Update libc.pot and NEWS.
      Update for glibc 2.24 release.

Chris Metcalf (2):
      Bump up tst-malloc-thread-fail timeout from 20 to 30s
      tile: only define __ASSUME_ALIGNED_REGISTER_PAIRS for 32-bit

Chung-Lin Tang (2):
      Fix stdlib/tst-makecontext regression for Nios II
      Nios II localplt.data update: remove __eqsf2

Claude Paroz (1):
      localedata: ln_CD: new locale [BZ #12676]

Dimitris Pappas (1):
      charmaps: IBM875: fix mapping of iota/upsilon variants [BZ #18453]

Dmitry V. Levin (1):
      intl: reintroduce unintentionally disabled optimization

Dylan Alex Simon (1):
      math: don't clobber old libm.so on install [BZ #19822]

Eduardo Trápani (1):
      localedata: eo: new Esperanto locale [BZ #16190]

Florian Weimer (91):
      tst-malloc-thread-exit: Use fewer system resources
      Remove trailing newline from date_fmt in Serbian locales [BZ #19581]
      Improve file descriptor checks for posix_spawn actions [BZ #19505]
      res_ninit: Update comment
      malloc: Remove arena_mem variable
      malloc: Remove max_total_mem member form struct malloc_par
      malloc: Remove NO_THREADS
      Deprecate readdir_r, readdir64_r [BZ #19056]
      test-skeleton.c: Do not set RLIMIT_DATA [BZ #19648]
      tst-audit4, tst-audit10: Compile AVX/AVX-512 code separately [BZ #19269]
      libio: Clean up _IO_file_doallocate and _IO_wfile_doallocate
      ldconfig: Do not remove stale symbolic links with -X [BZ #19610]
      sunrpc: In key_call_keyenvoy, use int status instead of union wait
      tst-audit10: Fix compilation on compilers without bit_AVX512F [BZ #19860]
      resolv: Always set *resplen2 out parameter in send_dg [BZ #19791]
      nss_db: Propagate ERANGE error if parse_line fails [BZ #19837]
      CVE-2016-3075: Stack overflow in _nss_dns_getnetbyname_r [BZ #19879]
      Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]
      strfmon_l: Use specified locale for number formatting [BZ #19633]
      scratch_buffer_set_array_size: Include <limits.h>
      hsearch_r: Include <limits.h>
      Add missing bug number to ChangeLog
      nss_dns: Fix assertion failure in _nss_dns_getcanonname_r [BZ #19865]
      Remove union wait [BZ #19613]
      malloc: Run fork handler as late as possible [BZ #19431]
      malloc: Remove unused definitions of thread_atfork, thread_atfork_static
      malloc: Remove malloc hooks from fork handler
      malloc: Add missing internal_function attributes on function definitions
      vfprintf: Fix memory with large width and precision [BZ #19931]
      resolv: Always set *resplen2 out parameter in send_vc [BZ #19825]
      nss_dns: Validate RDATA length against packet length [BZ #19830]
      resolv, nss_dns: Remove remaining syslog logging [BZ #19862]
      nss_dns: Check address length before creating addrinfo result [BZ #19831]
      nss_dns: Remove custom offsetof macro definition
      nss_dns: Skip over non-PTR records in the netent code [BZ #19868]
      Fix ChangeLog date to reflect commit date
      resolv: Remove SCCS and RCS keywords
      resolv: Remove _LIBC conditionals
      inet: Remove SCCS keywords
      resolv: Remove BIND_UPDATE preprocessor conditionals
      resolv: Remove RESOLVSORT preprocess conditionals
      resolv: Remove RFC1535 conditionals
      resolv: Remove traces of ULTRIX support
      resolv: Remove __BIND_NOSTATIC conditionals
      resolv: Remove BSD compatibility conditionals and header
      resolv: Remove SUNSECURITY preprocessor conditionals
      resolv: Assorted preprocessor cleanups
      resolv: Reindent preprocessor conditionals following cleanups
      getnameinfo: Do not preserve errno
      glob: Simplify the interface for the GLOB_ALTDIRFUNC callback gl_readdir
      CVE-2016-3706: getaddrinfo: stack overflow in hostent conversion [BZ
#20010]
      NEWS entry for CVE-2016-3075
      getnameinfo: Refactor and fix memory leak [BZ #19642]
      hesiod: Remove RCS keywords
      hesiod: Remove DEF_RHS
      hesiod: Always use thread-local resolver state [BZ #19573]
      hesiod: Avoid heap overflow in get_txt_records [BZ #20031]
      CVE-2016-1234: glob: Do not copy d_name field of struct dirent [BZ
#19779]
      getnameinfo: Reduce line length and add missing comments
      getnameinfo: Avoid calling strnlen on uninitialized buffer
      getnameinfo: Return EAI_OVERFLOW in more cases [BZ #19787]
      malloc: Adjust header file guard in malloc-internal.h
      getaddrinfo: Restore RES_USE_INET6 flag on error path [BZ #19994]
      resolv: Call gmtime_r instead of gmtime in p_secstodate [BZ #20017]
      localedef: Do not compile with mcheck
      getaddrinfo: Convert from extend_alloca to struct scratch_buffer
      Increase fork signal safety for single-threaded processes [BZ #19703]
      malloc: Rewrite dumped heap for compatibility in __malloc_set_state
      tst-mallocfork2: Fix race condition, use fewer resources
      Make padding in struct sockaddr_storage explicit [BZ #20111]
      CVE-2016-4429: sunrpc: Do not use alloca in clntudp_call [BZ #20112]
      malloc: Correct malloc alignment on 32-bit architectures [BZ #6527]
      fork in libpthread cannot use IFUNC resolver [BZ #19861]
      libio: Use wmemset instead of __wmemset to avoid linknamespace issue
      tst-rec-dlopen: Use interposed malloc instead of hooks
      malloc: Correct size computation in realloc for dumped fake mmapped
chunks
      quick_exit tests: Do not use C++ headers
      malloc: Remove __malloc_initialize_hook from the API [BZ #19564]
      fopencookie: Mangle function pointers stored on the heap [BZ #20222]
      malloc_usable_size: Use correct size for dumped fake mapped chunks
      nss_db: Fix initialization of iteration position [BZ #20237]
      debug/tst-longjmp_chk2: Make signal handler more conservative [BZ #20248]
      Revert __malloc_initialize_hook symbol poisoning
      elf: Consolidate machine-agnostic DTV definitions in <dl-dtv.h>
      malloc: Avoid premature fallback to mmap [BZ #20284]
      test-skeleton.c: Add write_message function
      test-skeleton.c: xmalloc, xcalloc, xrealloc are potentially unused
      test-skeleton.c (xrealloc): Support realloc-as-free
      libio: Implement vtable verification [BZ #20191]
      Correct bug number in ChangeLog [BZ #18960]
      CVE-2016-5417 was assigned to bug 19257

Gabriel F. T. Gomes (3):
      powerpc: Remove uses of operand modifier (%s) in inline asm
      powerpc: Zero pad using memset in strncpy/stpncpy
      powerpc: Fix operand prefixes

Gunnar Hjalmarsson (1):
      localedata: id_ID: Februari instead of Pebruari [BZ #20316]

Gustavo Romero (1):
      powerpc: Fix missing verb and typo in comment about AT_HWCAP entry

Guy Rutenberg (1):
      localedata: en_IL: new English locale [BZ #19963]

H.J. Lu (68):
      [x86_64] Set DL_RUNTIME_UNALIGNED_VEC_SIZE to 8
      Call x86-64 __setcontext directly
      Call x86-64 __mcount_internal/__sigjmp_save directly
      Copy x86_64 _mcount.op from _mcount.o
      Or bit_Prefer_MAP_32BIT_EXEC in EXTRA_LD_ENVVARS
      x86-64: Fix memcpy IFUNC selection
      Add a comment in sysdeps/x86_64/Makefile
      Replace @PLT with @GOTPCREL(%rip) in call
      Replace PREINIT_FUNCTION@PLT with *%rax in call
      Use HAS_ARCH_FEATURE with Fast_Rep_String
      Group AVX512 functions in .text.avx512 section
      Support --enable-hardcoded-path-in-tests in benchtests
      Define _HAVE_STRING_ARCH_mempcpy to 1 for x86
      Add _arch_/_cpu_ to index_*/bit_* in x86 cpu-features.h
      Use JUMPTARGET in x86-64 mathvec
      Use JUMPTARGET in x86-64 pthread
      Set index_arch_AVX_Fast_Unaligned_Load only for Intel processors
      Don't set %rcx twice before "rep movsb"
      [x86] Add a feature bit: Fast_Unaligned_Copy
      Implement x86-64 multiarch mempcpy in memcpy
      Make __memcpy_avx512_no_vzeroupper an alias
      Initial Enhanced REP MOVSB/STOSB (ERMS) support
      Add x86-64 memmove with unaligned load/store and rep movsb
      Add x86-64 memset with unaligned store and rep stosb
      Test 64-byte alignment in memcpy benchtest
      Test 64-byte alignment in memmove benchtest
      Test 64-byte alignment in memset benchtest
      Remove Fast_Copy_Backward from Intel Core processors
      Fix memmove-vec-unaligned-erms.S
      Don't put SSE2/AVX/AVX512 memmove/memset in ld.so
      Add a comment in memset-sse2-unaligned-erms.S
      Force 32-bit displacement in memset-vec-unaligned-erms.S
      Add memcpy/memmove/memset benchmarks with large data
      X86-64: Prepare memset-vec-unaligned-erms.S
      X86-64: Prepare memmove-vec-unaligned-erms.S
      X86-64: Use non-temporal store in memcpy on large data
      Detect Intel Goldmont and Airmont processors
      Reduce number of mmap calls from __libc_memalign in ld.so
      Move sysdeps/x86_64/cacheinfo.c to sysdeps/x86
      Remove x86 ifunc-defines.sym and rtld-global-offsets.sym
      Support non-inclusive caches on Intel processors
      Call init_cpu_features only if SHARED is defined
      Clear destination buffer updated by the previous run
      Don't call internal __pthread_unwind via PLT
      Don't call internal _Unwind_Resume via PLT
      Remove alignments on jump targets in memset
      Check the HTT bit before counting logical threads
      Correct Intel processor level type mask from CPUID
      Remove special L2 cache case for Knights Landing
      Avoid an extra branch to PLT for -z now
      Count number of logical processors sharing L2 cache
      Fix a typo in comments in memmove-vec-unaligned-erms.S
      Check FMA after COMMON_CPUID_INDEX_80000001
      X86-64: Remove the previous SSE2/AVX2 memsets
      X86-64: Remove previous default/SSE2/AVX2 memcpy/memmove
      X86-64: Add dummy memcopy.h and wordcopy.c
      Always indirect branch to __libc_start_main via GOT
      Compile tst-cleanupx4 test with -fexceptions
      Check Prefer_ERMS in memmove/memcpy/mempcpy/memset
      Require binutils 2.24 to build x86-64 glibc [BZ #20139]
      Make copies of cstdlib/cmath and use them [BZ #20314]
      X86-64: Define LO_HI_LONG to skip pos_h [BZ #20349]
      x86-64: Properly align stack in _dl_tlsdesc_dynamic [BZ #20309]
      Test p{read,write}64 with offset > 4GB
      x86-64: Add p{read,write}[v]64 to syscalls.list [BZ #20348]
      Regenerate i686 libm-test-ulps with GCC 6.1 at -O3 [BZ #20347]
      i386: Compile rtld-*.os with -mno-sse -mno-mmx -mfpmath=387
      Don't compile do_test with -mavx/-mavx/-mavx512

Hongjiu Zhang (1):
      sln: use stat64

Jiyoung Yun (1):
      Fix robust mutex daedlock [BZ #20263]

John David Anglin (2):
      hppa: fix loading of global pointer in _start [BZ #20277]
      hppa: Update libm-test-ulps.

Joseph Myers (107):
      Fix ldbl-128ibm floorl for non-default rounding modes (bug 17899).
      Fix ldbl-128ibm ceill for non-default rounding modes (bug 19592).
      Fix ldbl-128ibm truncl for non-default rounding modes (bug 19593).
      Fix ldbl-128ibm roundl for non-default rounding modes (bug 19594).
      Fix ldbl-128ibm fmodl handling of subnormal results (bug 19595).
      Fix ldbl-128ibm fmodl handling of equal arguments with low part zero (bug
19602).
      Fix ldbl-128ibm remainderl, remquol equality tests (bug 19603).
      Fix ldbl-128ibm powl overflow handling (bug 19674).
      Fix ldbl-128ibm nextafterl, nexttowardl sign of zero result (bug 19678).
      Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere.
      Remove linux/fanotify.h configure test.
      Remove kernel-features.h conditionals on pre-3.2 kernels.
      Fix ldbl-128ibm remainderl equality test for zero low part (bug 19677).
      Fix ldbl-128ibm nearbyintl in non-default rounding modes (bug 19790).
      Allow spurious underflow / inexact for ldbl-128ibm.
      Update glibc headers for Linux 4.5.
      Adjust kernel-features.h defaults for socket syscalls.
      Remove __ASSUME_PPOLL.
      Remove __ASSUME_FALLOCATE.
      Remove __ASSUME_EVENTFD2, move eventfd to syscalls.list.
      Remove __ASSUME_SIGNALFD4.
      Remove __ASSUME_GETDENTS64_SYSCALL.
      Fix x86_64 / x86 powl inaccuracy for integer exponents (bug 19848).
      [microblaze] Remove __ASSUME_FUTIMESAT.
      Fix termios.h XCASE namespace (bug 19925).
      Fix limits.h NL_NMAX namespace (bug 19929).
      Fix stdio.h cuserid namespace (bug 19989).
      Define off_t in stdio.h for XOPEN2K.
      conformtest: Correct XOPEN2K stdarg.h expectations.
      Fix langinfo.h nl_langinfo_l namespace (bug 19996).
      conformtest: Correct some signal.h expectations for XOPEN2K.
      conformtest: Correct some stdio.h expectations for UNIX98.
      conformtest: Correct stdio.h expectations for fdopen.
      Also define off_t in stdio.h for UNIX98.
      conformtest: Add langinfo.h expectations for YESSTR, NOSTR.
      Fix stdio.h namespace for pre-threads POSIX (bug 20014).
      Fix fcntl.h timespec namespace (bug 20023).
      Fix sys/time.h timespec namespace (bug 20041).
      conformtest: Remove some bogus sys/types.h expectations for XPG3 and
XPG4.
      Declare cuserid in unistd.h for UNIX98 and before (bug 20043).
      Declare pthread_atfork in unistd.h for UNIX98 (bug 20044).
      conformtest: Fix st_blksize, st_blocks expectations for XPG3, XPG4.
      conformtest: Correct some sys/stat.h expectations for XPG3.
      Fix sys/stat.h fchmod namespace (bug 20073).
      Declare tcgetsid for XPG4 (bug 20055).
      conformtest: Do not expect S_IF* in fcntl.h.
      Declare gethostname for XPG4 (bug 20054).
      conformtest: Correct some unistd.h expectations for XPG3, XPG4.
      conformtest: Correct time.h XPG3 expectations.
      conformtest: Do not expect strdup in string.h for XPG3.
      conformtest: Correct some stdlib.h expectations for XPG3.
      Correct ttyslot header declaration conditions (bug 20051).
      Fix stdlib.h rand_r namespace (bug 20074).
      Make sys/stat.h define S_IFSOCK, S_ISSOCK for XPG4 (bug 20076).
      Do not declare grantpt, ptsname, unlockpt in stdlib.h for XPG3 (bug
20094).
      Add Q_GETNEXTQUOTA from Linux 4.6 to sys/quota.h.
      Add CLONE_NEWCGROUP from Linux 4.6 to bits/sched.h.
      Update libm-test.inc comment about NaN signs.
      conformtest: Correct search.h expectations for XPG3.
      conformtest: Correct pwd.h expectations for XPG3.
      Implement proper fmal for ldbl-128ibm (bug 13304).
      conformtest: Correct ftw.h expectations for XPG3, XPG4.
      Update sysdeps/unix/sysv/linux/bits/socket.h for Linux 4.6.
      conformtest: Correct some limits.h expectations for XPG3, XPG4.
      Do not raise "inexact" from generic ceil (bug 15479).
      Do not raise "inexact" from generic floor (bug 15479).
      Do not raise "inexact" from generic round (bug 15479).
      Do not raise "inexact" from x86_64 SSE4.1 ceil, floor (bug 15479).
      Do not raise "inexact" from powerpc32 ceil, floor, trunc (bug 15479).
      Do not raise "inexact" from powerpc64 ceil, floor, trunc (bug 15479).
      Support sNaN testing in libm-test.inc.
      Add more sNaN tests to libm-test.inc.
      Fix ldbl-128 j0l, j1l, y0l, y1l for sNaN argument (bug 20151).
      Fix ldbl-128ibm sqrtl (sNaN) (bug 20153).
      Fix ldbl-128ibm ceill, rintl etc. for sNaN arguments (bug 20156).
      Remove unused macros from libm-test.inc.
      Avoid "invalid" exceptions from powerpc fabsl (sNaN) (bug 20157).
      Fix powerpc32 ceil, rint etc. on sNaN input (bug 20160).
      Fix powerpc64 ceil, rint etc. on sNaN input (bug 20160).
      Fix x86/x86_64 nextafterl incrementing negative subnormals (bug 20205).
      Fix dbl-64 acos (sNaN) (bug 20212).
      Fix dbl-64 asin (sNaN) (bug 20213).
      Fix i386 asinhl (sNaN) (bug 20218).
      Fix i386 atanhl (sNaN) (bug 20219).
      Fix i386 cbrtl (sNaN) (bug 20224).
      Fix ldexp, scalbn, scalbln for sNaN input (bug 20225).
      Fix i386/x86_64 expl, exp10l, expm1l for sNaN input (bug 20226).
      Fix i386/x86_64 logl (sNaN) (bug 20227).
      Fix i386/x86_64 log10l (sNaN) (bug 20228).
      Fix i386/x86_64 log1pl (sNaN) (bug 20229).
      Fix ldbl-128 expm1l (sNaN) (bug 20232).
      Fix ldbl-128ibm expm1l (sNaN) (bug 20233).
      Fix ldbl-128ibm log1pl (sNaN) (bug 20234).
      Fix i386/x86_64 log2l (sNaN) (bug 20235).
      Fix modf (sNaN) (bug 20240).
      Fix frexp (NaN) (bug 20250).
      Add more sNaN tests (cimag, conj, copysign, creal, fma, fmod).
      Fix dbl-64 atan2 (sNaN, qNaN) (bug 20252).
      Simplify generic fdim implementations.
      Use generic fdim on more architectures (bug 6796, bug 20255, bug 20256).
      Fix i386 fdim double rounding (bug 20255).
      Simplify x86 nearbyint functions.
      Add more sNaN tests (most remaining real functions).
      Fix i386/x86_64 scalbl with sNaN input (bug 20296).
      Avoid "inexact" exceptions in i386/x86_64 ceil functions (bug 15479).
      Avoid "inexact" exceptions in i386/x86_64 floor functions (bug 15479).
      Avoid "inexact" exceptions in i386/x86_64 trunc functions (bug 15479).

Khem Raj (2):
      When disabling SSE, make sure -fpmath is not set to use SSE either
      elf: Define missing Meta architecture specific relocations

Maciej W. Rozycki (1):
      Treat STV_HIDDEN and STV_INTERNAL symbols as STB_LOCAL

Mark Wielaard (2):
      elf/elf.h: Add new 386 and X86_64 relocations from binutils.
      elf.h: Add NT_ARM_SYSTEM_CALL constant.

Marko Myllynen (1):
      localedef: drop unused --old-style

Martin Galvan (1):
      Add pretty printers for the NPTL lock types

Matthew Fortune (1):
      VDSO support for MIPS

Matthias Wallnoefer (2):
      localedata: de_{AT,CH}: copy data from de_DE
      localedata: de_IT: new locale

Mike FABIAN (1):
      localedata: i18n: fix typos in tel_int_fmt

Mike Frysinger (44):
      locledata: trim trailing blank lines/comments
      localedata: dz_BT/ps_AF: reformat data
      localedata: CLDRv28: update LC_TELEPHONE.int_prefix
      locales: pap_AN: delete old/deprecated locale [BZ #16003]
      test-skeleton: increase default TIMEOUT to 20 seconds
      localedata: an_ES: fix lang_ab value
      localedata: es_PR: change LC_MEASUREMENT to metric
      localedata: clear LC_IDENTIFICATION tel/fax fields
      link sln fix to bugzilla [BZ #15333]
      localedata: use same comment_char/escape_char in these files
      add ChangeLog entry
      localedata: standardize first few lines
      localedata: standardize copyright/license information [BZ #11213]
      localedata: iw_IL: delete old/deprecated locale [BZ #16137]
      configure: fix `test ==` usage
      localedata: CLDRv28: update LC_PAPER values
      localedata: LC_TIME.date_fmt: delete entries same as the default value
      localedata: CLDRv29: update LC_IDENTIFICATION language/territory fields
      localedata: LC_MEASUREMENT: use copy directives everywhere
      localedata: LC_PAPER: use copy directives everywhere
      localedata: CLDRv29: update LC_ADDRESS.country_num values
      localedata: fix LC_ADDRESS.country_car entries
      localedata: CLDRv29: update LC_ADDRESS.country_name translations
      localedata: LC_IDENTIFICATION.category: set to ISO 30112 2014 standard
      localedef: check LC_IDENTIFICATION.category values
      localedata: CLDRv29: update LC_MONETARY int_curr_symbol & currency_symbol
      localedata: LC_IDENTIFICATION: delete uncommon fields
      locale: ld-telephone: update to ISO-30112 2014
      localedef: allow %l/%n in postal_fmt [BZ #16983]
      localedata: fix LC_TELEPHONE in a few locales
      localedata: CLDRv29: update LC_TIME week/first_week,workday fields
      localedef: change week_1stweek default to 7
      localedata: standard LC_MESSAGES string regexes a bit
      localedata: LC_MESSAGES.{yes,no}expr: add +1/-0 to all regexes [BZ
#15263]
      localedata: LC_MESSAGES.{yes,no}expr: standardize yY/nN [BZ #15262]
      localedata: CLDRv29: update LC_MESSAGES yes/no strings [BZ #15264] [BZ
#16975]
      tst-langinfo: update yesexpr/noexpr baselines
      tst-fmon/tst-numeric: switch malloc to static stack space [BZ #19671]
      localedata: add more translit entries
      localedata: pt_BR/pt_PT: make days/months lowercase [BZ #19133]
      unicode-gen: include standard comment file header
      NEWS: clarify localedef --old-style update
      manual: fix spelling typos
      microblaze: fix variable name collision with syscall macros

Neskie Manuel (1):
      localedata: chr_US: new Cherokee locale [BZ #12143]

Nick Alcock (2):
      x86, pthread_cond_*wait: Do not depend on %eax not being clobbered
      Allow overriding of CFLAGS as well as CPPFLAGS for rtld.

Paras pradhan (1):
      localedata: ne_NP: misc updates [BZ #1170]

Paul E. Murphy (22):
      Increase internal precision of ldbl-128ibm decimal printf [BZ #19853]
      powerpc: Add optimized P8 strspn
      powerpc: Add optimized strcspn for P8
      powerpc: Add missing insn in swapcontext [BZ #20004]
      Refactor bug-strtod.c to better test new types.
      Refactor bug-strtod2.c to be type generic
      Refactor tst-strtod6.c
      Refactor tst-strtod-round.c
      Fixup usage of MANT_DIG in libm-test.inc
      Fixup usage of MIN_EXP in libm-test.inc
      Refactor tst-strtod-round.c for type-generic-ness
      Begin refactor of libm-test.inc
      Refactor type specific macros using regexes
      Refactor M_ macros defined in libm-test.inc
      Replace M_PI2l with lit_pi_2_d in libm-test.inc
      Replace M_PIl with lit_pi in libm-test.inc
      Replace M_PI_4l with lit_pi_4_d in libm-test.inc
      Replace M_El with lit_e in libm-test.inc
      Apply LIT(x) to floating point literals in libm-test.c
      Remove CHOOSE() macro from libm-tests.inc
      Remove type specific information from auto-libm-test-in
      Generate new format names in auto-libm-test-out

Paul Pluzhnikov (7):
      2016-03-03  Paul Pluzhnikov  <ppluzhnikov@google.com>
      2016-05-30  Paul Pluzhnikov  <ppluzhnikov@google.com>
      Merge branch 'master' of ssh://sourceware.org/git/glibc
      2016-06-05  Paul Pluzhnikov  <ppluzhnikov@google.com>
      2016-06-09  Paul Pluzhnikov  <ppluzhnikov@gmail.com>
      2016-06-11  Paul Pluzhnikov  <ppluzhnikov@google.com>
      Fix rt/tst-aio64.c as well, and mention login/tst-utmp.c in ChangeLog

Rajalakshmi Srinivasaraghavan (4):
      powerpc: Rearrange cfi_offset calls
      powerpc: strcasestr optmization for power8
      Add nextup and nextdown math functions
      powerpc: Fix return code of strcasecmp for unaligned inputs

Rical Jasan (9):
      manual: fix typos in the memory chapter
      manual: fix typos in the character handling chapter
      manual: fix typos in the string chapters
      manual: fix typos in character set handling
      manual: fix typos in the locale chapter
      manual: fix typos in the locale chapter
      manual: fix typos in the message chapter
      manual: fix typos in the search chapter
      manual: fix typos in the pattern chapter

Richard Henderson (2):
      elf.h: Sync with the gabi webpage
      elf.h: Add declarations for BPF

Robin van der Vliet (1):
      locale: iso-639: add Talossan language [BZ #19400]

Roland McGrath (9):
      Add fts64_* to sysdeps/arm/nacl/libc.abilist
      Typo fixes.
      Gratuitous change to poke buildbot.
      Fix c++-types-check conditionalization.
      Omit test-math-isinff when no C++ compiler.
      Conditionalize c++-types-check.out addition to tests-special.
      Fix edito in last change.
      Fix tst-audit10 build when -mavx512f is not supported.
      stpcpy is part of POSIX.1-2008 [BZ #3629]

Samuel Thibault (23):
      Fix flag test in waitid compatibility layer
      Fix hurd build
      hurd: Break errnos.d / libc-modules.h dependency loop
      Fix mach-syscalls.mk build
      hurd: Do not hide rtld symbols which need to be preempted
      hurd: Allow inlining IO locks
      hurd: Add c++-types expected result
      Fix malloc threaded tests link on non-Linux
      Fix crash on getauxval call without HAVE_AUX_VECTOR
      Fix build with HAVE_AUX_VECTOR
      hurd: fix profiling short-living processes
      Fix gprof timing
      non-linux: Apply RFC3542 obsoletion of RFC2292 macros
      non-linux: Apply RFC3542 obsoletion of RFC2292 macros
      aio: fix newp->running data race
      Revert "aio: fix newp->running data race"
      hurd: fix _hurd_self_sigstate reference from ____longjmp_chk
      Add more hurd exception to local headers list
      hurd: disable ifunc for now
      mach: Add mach_print sycsall declaration
      hurd: Fix PTR_{,DE}MANGLE calls
      Add missing changelog part
      Fix TABDLY value

Siddhesh Poyarekar (10):
      New make target to only build benchmark binaries
      Fix up ChangeLog formatting
      benchtests: Update README to include instructions for bench-build target
      Fix up ChangeLog
      benchtests: Clean up extra-objs
      benchtests: Support for cross-building benchmarks
      Avoid attempt for runtime checks if all environments are defined
      Fix up ChangeLog
      Revert "Add pretty printers for the NPTL lock types"
      Fix cos computation for multiple precision fallback (bz #20357)

Simion Onea (1):
      localedata: ro_RO: update Tuesday translation [BZ #18911]

Stefan Liebler (31):
      Add missing inclusion of libc-internal.h.
      S390: Save and restore fprs/vrs while resolving symbols.
      S390: Extend structs La_s390_regs / La_s390_retval with vector-registers.
      S390: Use ahi instead of aghi in 32bit _dl_runtime_resolve.
      Mention Bug in ChangeLog for S390: Save and restore fprs/vrs while
resolving symbols.
      Fix strfmon_l: Use specified locale for number formatting [BZ #19633]
      Add missing iucv related defines.
      S390: Add support for vdso getcpu symbol.
      S390: Use fPIC to avoid R_390_GOT12 relocation in gcrt1.o.
      Fix tst-cancel17/tst-cancelx17, which sometimes segfaults while exiting.
      S390: Use mvcle for copies > 1MB on 32bit with default memcpy variant.
      S390: Use 64bit instruction to check for copies of > 1MB with mvcle.
      S390: Do not call memcpy, memcmp, memset within libc.so via ifunc-plt.
      S390: Implement mempcpy with help of memcpy. [BZ #19765]
      S390: Get rid of make warning: overriding recipe for target
gconv-modules.
      S390: Configure check for vector support in gcc.
      S390: Optimize 8bit-generic iconv modules.
      S390: Optimize builtin iconv-modules.
      S390: Optimize iso-8859-1 to ibm037 iconv-module.
      S390: Optimize utf8-utf32 module.
      S390: Optimize utf8-utf16 module.
      S390: Optimize utf16-utf32 module.
      S390: Use s390-64 specific ionv-modules on s390-32, too.
      S390: Fix utf32 to utf8 handling of low surrogates (disable cu41).
      S390: Fix utf32 to utf16 handling of low surrogates (disable cu42).
      Fix ucs4le_internal_loop in error case. [BZ #19726]
      Fix UTF-16 surrogate handling. [BZ #19727]
      tst-rec-dlopen: Fix build fail due to missing inclusion of string.h
      S390: Fix relocation of _nl_current_LC_CATETORY_used in static build. [BZ
#19860]
      S390: Use DT_JUMPREL in prelink undo code.
      S390: Do not clobber r13 with memcpy on 31bit with copies >1MB.

Stephen Gallagher (1):
      NSS: Implement group merging support.

Szabolcs Nagy (4):
      [AArch64] Fix libc internal asm profiling code
      [AArch64] Add bits/hwcap.h for aarch64 linux
      [AArch64] Regenerate libm-test-ulps
      [AArch64] Update libm-test-ulps

Timur Birsh (1):
      localedata: kk_KZ: various updates [BZ #15578]

Torvald Riegel (1):
      Remove atomic_compare_and_exchange_bool_rel.

Tulio Magno Quites Machado Filho (3):
      Fix type of parameter passed by malloc_consolidate
      powerpc: Fix --disable-multi-arch build on POWER8
      powerpc: Add a POWER8-optimized version of expf()

Wilco Dijkstra (7):
      Improve generic strcspn performance
      Remove pre GCC3.2 optimizations from string/bits/string2.h.
      Move mempcpy, strcpy and stpcpy inlines to string/string-inlines.c as
compatibility
      This is an optimized memset for AArch64.  Memset is split into 4 main
cases:
      This is an optimized memcpy/memmove for AArch64.  Copies are split into 3
main
      Add a simple rawmemchr implementation.  Use strlen for rawmemchr(s, '\0')
as it
      This patch further tunes memcpy - avoid one branch for sizes 1-3,

Will Newton (1):
      elf/elf.h: Add missing Meta relocations

Yvan Roux (1):
      Suppress GCC 6 warning about ambiguous 'else' with -Wparentheses

Zack Weinberg (3):
      Move sysdeps/generic/bits/hwcap.h to top-level bits/
      Move sysdeps/generic/bits/hwcap.h to top-level bits/
      Don't install the internal header grp-merge.h

raji (1):
      powerpc: strcasecmp/strncasecmp optmization for power8

ricaljasan@pacific.net (2):
      manual: fix typo in the introduction
      manual: fix typos in error reporting

-----------------------------------------------------------------------

-- 
You are receiving this mail because:
You are the assignee for the bug.