incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: GPL'd dictionaries (was Re:
Date Sun, 06 Nov 2011 23:05:44 GMT
On Sun, Nov 6, 2011 at 5:18 PM, Pedro Giffuni <> wrote:
> --- On Sun, 11/6/11, Rob Weir <> wrote:
> ...
>> Dennis E. Hamilton  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@ 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.
> Makefiles are also a basically a list with little or no
> creative content and they don't even leave a trace in the code
> but we are relicensing them.

It varies from country to country, see:

But we'll never resolve this on legal grounds.  At Apache we would not
bundle a dictionary under a legal theory if the compiler of the
dictionary did not want us to.  I think we should respect the
dictionary compiler's wishes and intent, even if legally we're not
obligated to.

But we do have options:

1) The user can download the dictionaries onto their own machines, if
they agree to uphold the license.

2) We could have a UI in the product that helps the user download
dictionaries.  This could state the license and require the user to
click "agree".

3) We could contact the compilers of the dictionary and ask if they
would make them available under a difference license.   Generally
people make things available under an OSS license because they want to
see other projects use them.  If we tell them that a leading
application like OpenOffice can no longer user their dictionary, this
might persuade them to change their license.

4) We could convert another word list or dictionary, one that has a
better license,  into Hunspell format.

5) We could create a new dictionary.

> I am concerned that we are talking about the GPL. If it
> were MPL or a documentation license it would be different
> but last time we discussed it we were not accepting copyleft
> documentation either.
> cheers,
> Pedro.
>>   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:
>> > 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 []
>> > Sent: Sunday, November 06, 2011 12:57
>> > To:
>> > Subject: Re: GPL'd dictionaries (was Re:
>> >
>> > HI Andrea,
>> >
>> > This looks like some good questions for Apache Legal.
>> You should send this to legal-discuss@a.o.
>> >
>> > 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:
>> >> - 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.
>> >>
>> >> Regards,
>> >>  Andrea.
>> >
>> >

View raw message