Re: localedata (non-)copyright policy from FSF

[Chris Leonard <cjlhomeaddress at gmail dot com>]

On Wed, Feb 20, 2013 at 4:57 PM, Roland McGrath <roland@hack.frob.com> wrote:
> I got this from <license-internal@fsf.org> under
>         Subject: [gnu.org #804286] GLIBC Locales Files

>
> I don't know where your information "many of these files contain
> brief, contradictory, confusing and occasionally non-free licensing
> statements" came from.  It does not comport with the reality I see
> today.

See this ticket (and discussion)

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

See also:
Debian Bug report logs - #555168
Many locales files do not permit modification
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168


>>   "This file is a part of GLIBC and contains locale data.The Free
>> Software Foundation does not claim any copyright interest in the locale
>> data contained in this file. The foregoing does not affect the license
>> of GLIBC as a whole. It does not exempt you from the conditions of the
>> license if your use would otherwise be governed by that license."
>
> No formal text we use says "GLIBC".  It all says, "the GNU C Library".
> If we were to add boilerplate text to the files, it would be in keeping
> with the standards for such text elsewhere in our sources, and look like:

That is a fair point, "GNU C Library" is more descriptive than  "GLIBC".

> % This file is part of the GNU C Library and contains locale data.
> % The Free Software Foundation does not claim any copyright interest
> % in the locale data contained in this file.  The foregoing does not
> % affect the license of the GNU C Library as a whole.  It does not
> % exempt you from the conditions of the license if your use would
> % otherwise be governed by that license.
>

I believe this is part of a concerted effort by FSF to obtain feedback
from locale authors on the proposed change.

You will note that no changes have been made, no patches posted.  The
current state of glibc license/copyright text is a mess and a cause of
concern for downstreams (e.g. Debian, SugarLabs).

The reasons for the current state of affairs are manifold:

1) FSF has not required copyright assignments from locale authors (or
from contributors of corrections to locales).

2) It appears that there has been an absence of
harmonization/standardization with respect to the copyright/licensing
statements in locale files over time.

3) Numerous locales were apparently developed using previous locales
as templates, leading to the propagation of inadequate or truncated
copyright/license statements.

4) It can be argued that the nature of the information contained in
locale files (day names, month names, etc.)   falls into a grey zone
between obviously copyrightable "creative" contributions (like source
code) and large compilations of public domain information (e.g.
telephone directories) that may also enjoy copyright protection.  This
ambiguity is most likely the reason that copyright assignments have
not traditionally been required.

The question is what can be done to improve the current situation?
The FSF proposed language is one approach to address the current
situation.  It would be very desirable if the discussion could be
focused on improving the FSF proposed approach or suggesting an
alternative approach that also addresses the important issues.  Merely
rejecting the suggested language will not move this issue closer to a
resolution.

It would be very unwieldy and possibly un-necessary to require
copyright assignments on all locale submissions and changes.  Arguing
the position that locales consist primarily of widely available public
domain information compiled with de minimus "creative spark" is not a
denigration of the effort put into compiling them, but a strategy to
argue for the freedom to re-purpose such information from any source.
I've worked with others to submit several new locales and I don't
personally feel slighted by language that would allow the information
therein to be used widely without copyright or licensing restrictions.
 That was my intent in developing the locales in the first place.

cjl