This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


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

[Bug localedata/11213] localedata licencing issues


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 on the CC list for the bug.


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