On Sun, Nov 6, 2011 at 4:10 PM, Dennis E. Hamilton
<[email protected]> wrote:
> +1 I heartily agree with Dave's suggestion.
>
> The issue has been made very clear by Andrea and I think it would be good to 
> raise an issue on the LEGAL JIRA.  (Registration required, but I don't think 
> committer status is needed.)  Also, legal-discuss@ apache.org is an useful 
> place, but my experience is that eventually a LEGAL JIRA issue will obtain 
> more consistent attention.
>

Just make sure that you explain what a spell checking dictionary is.
Otherwise any legal types will be confused.  This is not a dictionary
like Webster's, with words and definitions, where the definitions are
creative content.  A spell checking dictionary is more of a word list.
  I'm not sure what the creative expression is in a list of all common
words in a language and how that could be copyrighted.  Of course, I
am not a lawyer.  But this case seems relevant:

http://en.wikipedia.org/wiki/Feist_v._Rural

> I also think Pedro raises an important concern.  My sense of other materials 
> I have seen about that is binaries (or at least not human-readable and 
> editable) might work since it is possible to make it clear that a non-Apache 
> license applies and there is no confusion by having source anywhere in a 
> release for something with an unacceptable license.  I don't know how this 
> applies to the present case.  I suspect it has some bearing on how safe 
> inclusion of various dictionaries in binary distributions is seen to be.
>
>  - Dennis
>
> -----Original Message-----
> From: Dave Fisher [mailto:[email protected]]
> Sent: Sunday, November 06, 2011 12:57
> To: [email protected]
> Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
>
> HI Andrea,
>
> This looks like some good questions for Apache Legal. You should send this to 
> [email protected].
>
> Regards,
> Dave
>
> On Nov 6, 2011, at 11:06 AM, Andrea Pescetti wrote:
>
>> 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:
>> - OpenOffice.org dictionaries are not code; their binary form is coincident 
>> with their source form.
>> - OpenOffice.org 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.
>> - OpenOffice.org 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 OpenOffice.org 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 OpenOffice.org, since it is "mere 
>> aggregation"; see the (long) story in
>> https://issues.apache.org/ooo/show_bug.cgi?id=65039
>>
>>> 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 
>> OpenOffice.org 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.
>>
>> Regards,
>>  Andrea.
>
>

Reply via email to