This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug localedata/11213] localedata licencing issues
- From: "keld at keldix dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Mon, 16 Jul 2012 17:04:02 +0000
- Subject: [Bug localedata/11213] localedata licencing issues
- Auto-submitted: auto-generated
- References: <bug-11213-131@http.sourceware.org/bugzilla/>
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 on the CC list for the bug.