incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject Re: GPL'd dictionaries (was Re:
Date Sun, 06 Nov 2011 19:06:58 GMT
On 05/11/2011 Gianluca Turconi wrote:
> 2011/11/5 Pedro Giffuni
>> I have been looking at the situation of the dictionaries,
>> and particular the italian dictionary.
>> You are right that it will not be covered by the SGA.

Sure, and to be more precise there are no portions of which Oracle has 
the copyright in the Italian dictionary. And we are discussing about 
three completeley separate tools (this is true of all languages): a 
dictionary (used for spell-checking), a thesaurus (for synonyms) and 
hyphenations patterns. Each has its own licence and copyright holders; 
in most cases, hyphenation patterns come from the LaTeX project.

>> Perhaps more worrying is that the italian dictionary is
>> the only dictionary under the GPL; most others are triple
>> licensed (LGPL/MPL/GPL).
>> We are not allowed to use it, so it will be removed
>> from the SVN server for sure.

The fundamental thing to consider here is that dictionaries cannot be 
considered like libraries, for the following reasons:
- dictionaries are not code; their binary form is 
coincident with their source form.
- dictionaries are not a dependency: they are pluggable 
data files, and they are packaged (all of them, even in the installer 
for native builds) as extensions to remark that there is no dependency 
whatsoever on them.
- dictionaries fall in the "mere aggregation" provision 
in the GPL license; even though it is customary to distribute a package 
containing, say, the Italian version of and the Italian 
dictionary, it is considered the same as distributing an Ubuntu ISO 
file, containing software with different licenses aggregated together.

The existing Apache policy probably assumes that we are talking about 
code and that the (L)GPL libraries constitute a dependency, and it was 
probably built by examining what the implications of (L)GPL components 
would have been in that case. But this is a much different situation.

>> I am not a lawyer and I don't have any idea how the
>> GPL could be enforced in this case, but things are not nice.

I can't understand these worries about enforcing the GPL. We even got an 
answer from the Free Software Foundation that said it is absolutely OK 
to include GPL dictionaries into, since it is "mere 
aggregation"; see the (long) story in

> We've discussed a lot about this issue, but  there isn't any consensus yet
> about *how *to solve the problem, in a pragmatic way that doesn't include a
> license change.

Gianluca is right, in our situation we won't be able to change the 
license of the dictionary and thesaurus (at least, not to Apache 
License); we might get the hyphenation patterns released under the 
Apache License, but since virtually all of them are taken from the LaTeX 
project it's probably better that the legal team checks whether it's 
fine to import from the LaTeX project with the existing license.

> An AOOo without a native language GUI and linguistic tools would be just
> useless outside the anglosaxon world and, indeed, a rather disastrous
> presentation of the new project for people who don't speak English.

Sure, especially considering that the project description says that supports 110 languages...

What I would recommend is:

1) Recheck the Apache policy and find out the rationale behind it; I 
have nothing to teach to the legal team, but this is a very rare case 
where the "virality" of GPL does not apply.

2) See if we can find a way to keep dictionaries as they are; note that 
no dictionary is developed in the OOo trunk, they are synchronized from 
time to time, usually before a release; the Italian dictionary SVN 
trunk, for example, is not in the OOo sources. Even just the possibility 
to provide an extension that can be included in binary releases would be 
OK for me.

3) If there is really no way to include a GPL extension this way, then 
we should think about downloading the extension at installation time. 
But we managed to get Sun and the FSF agree to ship dictionaries in the 
most convenient way (i.e., included in the installer), so we might 
succeed this time as well.


View raw message